Hi, (minor note - on PG lists the style is to quote in-line and trip)
On 2019-11-04 10:35:25 +0100, Josef Šimánek wrote: > Thanks for quick response. As I was testing this feature it shows all > "possible" triggers to be executed running given query. The benefit of > having this information in EXPLAIN as well is you do not need to execute > the query (as EXPLAIN ANALYZE does). My usecase is to take a look at query > before it is executed to get some idea about the plan with EXPLAIN. I can actually see some value in additional information here, but I'd probably want to change the format a bit. When explicitly desired (or perhaps just in verbose mode?), I see value in counting the number of triggers we know about that need to be checked, how many were excluded on the basis of the trigger's WHEN clause etc. > Do you have idea about some case where actual trigger will be missing in > EXPLAIN with current implementation, but will be present in EXPLAIN > ANALYZE? I can take a look if there's any way how to handle those cases as > well. Any triggers that are fired because of other, listed, triggers causing other changes. E.g. a logging trigger that inserts into a log table - EXPLAIN, without ANALYZE, doesn't have a way of knowing about that. And before you say that sounds like a niche issue - it's not in my experience. Forgetting the necessary indexes two or three foreign keys down a CASCADE chain seems to be more common than doing so for tables directly "linked" with busy ones. Greetings, Andres Freund
