Re: plan with result cache is very slow when work_mem is not enough

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: plan with result cache is very slow when work_mem is not enough
Дата
Msg-id 20210509190441.6wcxpp5543hg5oqz@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: plan with result cache is very slow when work_mem is not enough  (Yura Sokolov <y.sokolov@postgrespro.ru>)
Список pgsql-hackers
Hi,

On 2021-05-09 15:57:22 +0300, Yura Sokolov wrote:
> Occasionally there is a need to run cassert builds in production to
> catch an issue. It is usually ok if cassert build O(1) slower than
> optimized biuld (ie it is slower in some constant factor C). But
> if cassert build will be quadratically slower, it will unusable.

The memory context assertion overhead is more than O(1) expensive. I
think there's plenty other cases like it. We removed some (e.g. it used
to be that we scanned O(#shared_buffers) entries in the local pin table,
at the end of the transaction). I don't think we want to limit ourselves
to O(1) checks. That's not to say we should have a O(n^2) or such,
unless we have confidence n rarely will be big.

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Identify LWLocks in tracepoints
Следующее
От: Tom Lane
Дата:
Сообщение: Non-reproducible valgrind failure on HEAD