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
