Re: Slow planning time for simple query
От | Pavel Stehule |
---|---|
Тема | Re: Slow planning time for simple query |
Дата | |
Msg-id | CAFj8pRDcdnYtM811VOO9BcTf6QJLuH=tKtCLC3rSXL8Ld4d=Zg@mail.gmail.com обсуждение исходный текст |
Ответ на | Slow planning time for simple query (Jeremy Finzel <finzelj@gmail.com>) |
Ответы |
Re: Slow planning time for simple query
|
Список | pgsql-general |
2018-06-06 18:59 GMT+02:00 Jeremy Finzel <finzelj@gmail.com>:
Hello -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 table1WHERE source_id IN (SELECT id FROM table2 WHERE customer_id = $1);The actual execution time is sub-ms.We initially thought maybe catalog bloat? But we were able to reindex all of the highly churned catalog tables, and I even did VACUUM FULL on pg_attribute and pg_statistic, to no avail.There are no custom settings for pg_attribute for the given tables either.Interestingly, the problem goes away on a SAN snapshot of the target system.Any ideas of what else we could try? A PL function that caches the query plan works, but that is just a workaround.
more times I seen similar issue based on bloated indexes on table - pg in planning time detect min max from possible indexes
Regards
Pavel
Thanks!Jeremy
В списке pgsql-general по дате отправления: