| От | Tom Lane |
|---|---|
| Тема | Re: Increasing work_mem slows down query, why? |
| Дата | |
| Msg-id | 19893.1585586177@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Increasing work_mem slows down query, why? (Pavel Stehule <pavel.stehule@gmail.com>) |
| Ответы |
Re: Increasing work_mem slows down query, why?
|
| Список | pgsql-performance |
Pavel Stehule <pavel.stehule@gmail.com> writes:
> CTE scan has only 1100 rows, public.rhnpackagecapability has 490964 rows.
> But planner does hash from public.rhnpackagecapability table. It cannot be
> very effective.
[ shrug... ] Without stats on the CTE output, the planner is very
leery of putting it on the inside of a hash join. The CTE might
produce output that ends up in just a few hash buckets, degrading
the join to something not much better than a nested loop. As long
as there's enough memory to hash the known-well-distributed table,
putting it on the inside is safer and no costlier.
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера