Eric Gillum writes:
> Does not seem to improve if I turn off JIT.
AFAICT you're just getting sideswiped by the poor quality of our estimates
for messy sub-SELECTs :-(. v12 is estimating that it will get only one
row out of the information_schema.table_constraints sub-select, which
causes it to d
Does not seem to improve if I turn off JIT.
# show jit;
on
# explain analyze SELECT tc.table_name, ...
Planning Time: 8.806 ms
Execution Time: 511.249 ms
# set jit=false;
# show jit;
off
# explain analyze SELECT tc.table_name, ...
Planning Time: 8.980 ms
Execution Time: 506.016 ms
On Wed,
Have you tried with JIT turned off in PG12? The long running node
is ProjectSet type which is related to set returning functions. If that is
getting evaluated differently in PG12, that may be issue.
I had not run the script per se, I had run ANALYZE. I just re-upgraded to a
separate cluster and ran the provided script. The query still takes about
500ms.
On Wed, Feb 26, 2020 at 7:56 AM Adrian Klaver
wrote:
> On 2/25/20 8:53 PM, Eric Gillum wrote:
> > Hello,
> >
> > I've noticed a ~50x regres
On 2/25/20 8:53 PM, Eric Gillum wrote:
Hello,
I've noticed a ~50x regression in execution time for a query when moving
from Postgres 11.6 to 12.1. Here's an example:
SELECT tc.table_name, kcu.column_name, ccu.table_name AS
foreign_table_name, ccu.column_name AS foreign_column_name FROM
info
Hello,
I've noticed a ~50x regression in execution time for a query when moving
from Postgres 11.6 to 12.1. Here's an example:
SELECT tc.table_name, kcu.column_name, ccu.table_name AS
foreign_table_name, ccu.column_name AS foreign_column_name FROM
information_schema.table_constraints tc JOIN
info
