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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: plan with result cache is very slow when work_mem is not enough
Дата
Msg-id CAFj8pRDARdra1qfS8e15Y8pA=t-EGOcXcV53S7kxogf4cRGD8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: plan with result cache is very slow when work_mem is not enough  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: plan with result cache is very slow when work_mem is not enough  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers


pá 7. 5. 2021 v 21:56 odesílatel David Rowley <dgrowleyml@gmail.com> napsal:
On Sat, 8 May 2021 at 07:18, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> yes, the slowdown is related to debug assertions

With USE_ASSERT_CHECKING builds, I did add some code that verifies the
memory tracking is set correctly when evicting from the cache. This
code is pretty expensive as it loops over the entire cache to check
the memory accounting every time we evict something from the cache.
Originally, I had this code only run when some other constant was
defined, but I ended up changing it to compile that code in for all
assert enabled builds.

I considered that it might be too expensive as you can see from the
comment in [1].  I just wanted to get a few machines other than my own
to verify that the memory accounting code was working as expected.
There have been no complaints of any Assert failures yet, so maybe
it's safe to consider either removing the code entirely or just having
it run when some other more specific to purpose constant is defined.
If we did the latter, then I'd have concerns that nothing would ever
run the code to check the memory accounting, that's why I ended up
changing it to run with USE_ASSERT_CHECKING builds.

I understand. I think this is too slow for generic assertions, because the overhead is about 50x. 

But I understand, so it may be necessary to have this code active some time.

Regards

Pavel


David

[1] https://github.com/postgres/postgres/blob/master/src/backend/executor/nodeResultCache.c#L305

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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: plan with result cache is very slow when work_mem is not enough
Следующее
От: Erik Rijkers
Дата:
Сообщение: JSON doc example (matchiness)