Ten trigger na cache je potřeba, pokud je ta cache externí. Ale kdyby byla interně v serveru, tak na to žádný trigger potřeba není --- stačí prostě při odpovědi zaznamenat transakční ID všech tabulek, které byly ke konstrukci odpovědí potřeba, a při dalším stejném dotazu porovnat daná transakční ID --- pokud sedí, tak se nemusí nic počítat a může se hned vrátit odpověď. (externí cache by takhle napsat nešla, protože externí cache nezjistí, jaké tabulky byly k řešení dotazu použity)
V PostgreSQL neni transakcni id na tabulkach :(. a) by mne decentne zpomalilo vyhodnoceni provadeciho planu, protoze bych jej musel kontrolovat na shodu, b) by se mi zpomalil commit, protoze bych musel znevalidnit cache. Uznavam, ze u statictejsich www aplikaci to smysl ma. Je to jednodušší než použít cache v PHP. Nicméně php cache je ještě efektivnější, jelikož ušetřím connect (i poolovaný) do db a navíc většinou mám v cache html místo surových dat, která musím znovu zabalit do html.
Použitím pg na logicky jednodušších aplikacích nepřinese žádný efekt. Ten se dostaví až, když jsou db operace o něco komplikovanější - kdy se využití triggery, bohatší repertoár indexů, speciální datové typy (pole). Trochu komplikovanější e-shop už se v PostgreSQL vyplatí. Dost práce dokáži provést v databázi - a navíc jsou k dispozici externí uložené procedury v Perlu, Pythonu.