Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case) |
| Дата | |
| Msg-id | 18538.1226513800@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case) ("Brendan Jurd" <direvus@gmail.com>) |
| Ответы |
Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)
|
| Список | pgsql-hackers |
"Brendan Jurd" <direvus@gmail.com> writes:
> I guess my question is, what's the real benefit of going to all this
> trouble trying to prove that clauses are false?
Not having to scan gigabytes of data in an excluded partition, for
instance.
Now the docs do say
Currently, constraint_exclusion is disabled by default becausethe constraint checks are relatively expensive, and in
manycircumstanceswill yield no savings. It is recommended to turnthis on only if you are actually using partitioned
tablesdesignedto take advantage of the feature.
so we could argue that it's the OP's own fault if he turns this option
on for queries where long planning time isn't worth the trouble.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера