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

Поиск
Список
Период
Сортировка
От Yura Sokolov
Тема Re: plan with result cache is very slow when work_mem is not enough
Дата
Msg-id 2a23a9ca2c6f36f70205cb95a6905672@postgrespro.ru
обсуждение исходный текст
Ответ на 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  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
David Rowley писал 2021-05-09 04:01:
> On Sun, 9 May 2021 at 03:29, Pavel Stehule <pavel.stehule@gmail.com> 
> wrote:
>> Personally, I have not problem with too slow assertions, although it 
>> is not too practical. The main problem is some shock, and feeling so 
>> some is wrong. I spent 1 hour detecting if it is a bug or not.
> 
> Thanks for spending the time figuring out where the slowness came from.
> 
>> Can it be possible to identify this situation?
>> 
>> Maybe use some specific name of this routine - like
>> 
>> assert_only_check_xxxx
>> 
>> Then I can see this warning in perf, and I don't need to do other or 
>> deeper checks
> 
> I don't think we need to go around leaving clues for people who run
> perf on cassert builds. I think anyone doing that should just never
> expect any meaningful results.

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.

regards,
Yura



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

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Enhanced error message to include hint messages for redundant options error
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Corrected documentation of data type for the logical replication message formats.