Re: BUG #16390: Regression between 12.2 and 11.6 on a recursive query : very slow and overestimation of rows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: postgresql(at)thefreecat(dot)org
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16390: Regression between 12.2 and 11.6 on a recursive query : very slow and overestimation of rows
Date: 2020-04-25 21:49:40
Message-ID: 16626.1587851380@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> Everything started on a big recursive query working fine with a filled
> database (all tables contain at least a few rows). It executes in ~120ms.
> But the same query, on a nearly empty DB takes ~10000ms on 12.2 and still
> ~100ms on 11.6 (same DB, vacuumed full and analyzed).

FWIW, I get largely the same plan and runtime (~5ms) for this example on
11.x, 12.x, and HEAD, when using non-JIT-enabled builds. It looks like
most of your runtime on 12.x is going into JIT compilation:

> JIT:
> Functions: 36
> Options: Inlining true, Optimization true, Expressions true, Deforming
> true
> Timing: Generation 9.996 ms, Inlining 12.520 ms, Optimization 116.679 ms,
> Emission 57.894 ms, Total 197.090 ms

It's not too surprising that the system thinks that compiling the query
would be worth the effort, since it's overestimating the size of the
recursive union so much. But this toy example doesn't really prove
anything about that --- the misestimate is mostly because the planner
won't believe that an empty table is empty. Which most of the time is a
good safety feature, even if it goes off the rails in this particular
case.

In short: as is so often the case, examining the behavior on toy tables
is not going to tell much about your real problem. Please see

https://wiki.postgresql.org/wiki/Slow_Query_Questions

for guidance about better ways to identify performance problems.
And take the issue to pgsql-performance, because it's unlikely
there's a bug here.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-04-25 22:14:33 Re: BUG #16388: Different results when bitmap scan enabled/disabled
Previous Message David G. Johnston 2020-04-25 20:09:00 Re: Queries getting older values (autocommit enabled)