Re: [PATCH] Include triggers in EXPLAIN

From: Andres Freund <andres(at)anarazel(dot)de>
To: Josef Šimánek <josef(dot)simanek(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, pavel(dot)stehule(at)gmail(dot)com, Tomáš Vondra <tv(at)fuzzy(dot)cz>
Subject: Re: [PATCH] Include triggers in EXPLAIN
Date: 2019-11-04 18:00:28
Message-ID: 20191104180028.dwugks4742535vju@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-11-04 18:01:44 Re: [PATCH] contrib/seg: Fix PG_GETARG_SEG_P definition
Previous Message Jeff Janes 2019-11-04 17:59:02 Re: cost based vacuum (parallel)