Re: Slow planning time for simple query
От | Tom Lane |
---|---|
Тема | Re: Slow planning time for simple query |
Дата | |
Msg-id | 22136.1528312205@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Slow planning time for simple query (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: Slow planning time for simple query
|
Список | 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 по дате отправления: