Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0
В списке pgsql-performance по дате отправления:
| От | Justin Pryzby |
|---|---|
| Тема | Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0 |
| Дата | |
| Msg-id | 20181128041750.GH30707@telsasoft.com обсуждение исходный текст |
| Ответ на | Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0 (David Rowley <david.rowley@2ndquadrant.com>) |
| Список | pgsql-performance |
On Wed, Nov 28, 2018 at 05:03:15PM +1300, David Rowley wrote: > Does it still take that long after running ANALYZE on the partitioned table? Yes ; I've just reproduced the problem with a variation on Sanyo's query, retrofitted onto the empty "partbench" table you used for testing in July: https://www.postgresql.org/message-id/CAKJS1f8qkcwr2DULd%2B04rBmubHkKzp4abuFykgoPUsVM-4-38g%40mail.gmail.com Note, Sanyo's original query appears to be a poor-man's window function, joining two subqueries on a.value=max(b.value). I reduced issue to this: |postgres=# ANALYZE partbench; |postgres=# explain SELECT * FROM (SELECT a.i2-b.i2 n FROM partbench a, (SELECT i2 FROM partbench)b)b, (SELECT max(partbench.i3)m FROM partbench, (SELECT i3 FROM partbench)y )y WHERE m=n; |Time: 31555.582 ms (00:31.556) Justin
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера