From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Jeremy Finzel <finzelj(at)gmail(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Slow planning time for simple query |
Date: | 2018-06-06 19:10:05 |
Message-ID: | 22136.1528312205@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2018-06-06 18:59 GMT+02:00 Jeremy Finzel <finzelj(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2018-06-06 19:12:34 | Re: Using distinct in an aggregate prevents parallel execution? |
Previous Message | Pavel Stehule | 2018-06-06 18:52:02 | Re: Slow planning time for simple query |