Re: Slow planning time for simple query - Mailing list pgsql-general

From Tom Lane
Subject Re: Slow planning time for simple query
Date
Msg-id 22136.1528312205@sss.pgh.pa.us
Whole thread Raw
In response to Re: Slow planning time for simple query  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: Slow planning time for simple query  (Jerry Sievers <gsievers19@comcast.net>)
List pgsql-general
Pavel Stehule <pavel.stehule@gmail.com> writes:
> 2018-06-06 18:59 GMT+02:00 Jeremy Finzel <finzelj@gmail.com>:
>> We have an odd scenario on one of our OLTP systems, which behaves the same
>> way on a streamer, of a 700-1000ms planning time for a query like this:
>> SELECT *
>> FROM table1
>> WHERE  source_id IN (SELECT id FROM table2 WHERE customer_id = $1);

> more times I seen similar issue based on bloated indexes on table - pg in
> planning time detect min max from possible indexes

Oh, hmm, yeah it could be ye olde get_actual_variable_range() issue.
When this happens, are there perhaps a lot of recently-dead rows at either
extreme of the range of table1.source_id or table2.id?

We made a fix last year to improve that:
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=3ca930fc3
but it wasn't back-patched.

            regards, tom lane


pgsql-general by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Slow planning time for simple query
Next
From: Thomas Kellerer
Date:
Subject: Re: Using distinct in an aggregate prevents parallel execution?