Re: Increasing work_mem slows down query, why?

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Increasing work_mem slows down query, why?
Дата
Msg-id CAFj8pRCDcXOHqKHPztwxSAKkvGufo56-ThJdM=hG6rogcrquDg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Increasing work_mem slows down query, why?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance


po 30. 3. 2020 v 18:36 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
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.

ok

Regards

Pavel



                        regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Increasing work_mem slows down query, why?
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: BUG #16334: We recently upgraded PG version from 9.5 to 10.10and system performance is not so good