Re: plan with result cache is very slow when work_mem is not enough - Mailing list pgsql-hackers

From Yura Sokolov
Subject Re: plan with result cache is very slow when work_mem is not enough
Date
Msg-id 2a23a9ca2c6f36f70205cb95a6905672@postgrespro.ru
Whole thread Raw
In response to Re: plan with result cache is very slow when work_mem is not enough  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: plan with result cache is very slow when work_mem is not enough
List 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 by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Enhanced error message to include hint messages for redundant options error
Next
From: Peter Smith
Date:
Subject: Re: Corrected documentation of data type for the logical replication message formats.