Re: BUG #17871: JIT during postgresql_fdw remote_estimates EXPLAIN have very negatively effect on planning time

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, maxim.boguk@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-03-28T18:38:43Z
Lists: pgsql-bugs
Hi,

On 2023-03-28 11:33:41 -0700, Andres Freund wrote:
> On 2023-03-28 16:05:00 +1300, David Rowley wrote:
> > On Tue, 28 Mar 2023 at 10:38, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > I was wondering if we could skip doing even that much when
> > > EXEC_FLAG_EXPLAIN_ONLY is set.  Without a test case, though,
> > > I'm not very sure where the jitter is getting reached.
> > 
> > It seems to be coming from the qual initialisation in nodeSeqscan.c:
> > ie. ExecInitSeqScan -> ExecInitQual -> ExecReadyExpr ->
> > jit_compile_expr
> > 
> > I guess that means just add a check for EXEC_FLAG_EXPLAIN_ONLY in
> > jit_compile_expr, or only set the es_jit_flags bits in
> > standard_ExecutorStart() when not in EXEC_FLAG_EXPLAIN_ONLY. I'm not
> > really sure which of those is better, but the attached does the former
> > and seems to fix the issue.
> 
> I'm a bit worried about either of these making EXPLAIN less informative. Right
> now we can see whether and how much would be JITed without ANALYZE. After this
> not anymore.

I wonder if we should address the postgres_fdw case of potentially doing lots
of EXPLAINs by adding an option geared towards that?

Or perhaps even a dedicated function?  Generating an entire executor tree,
just to get to estimates that the planner already determined, seems a bit
questionable... Explain output can be quite large. And we are just looking at
the top-level cost + rows anyway?

Greetings,

Andres Freund