Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: David Rowley <dgrowleyml@gmail.com>, Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-09-04T20:36:55Z
Lists: pgsql-hackers
On 2020-08-05 05:00, David Rowley wrote:
> The 5GB scaled TPC-H test does show some performance gains from the v4
> patch and shows an obvious regression from removing the unlikely()
> calls too.
> 
> Based, mostly on the TPC-H results where performance did improve close
> to 2%, I'm starting to think it would be a good idea just to go for
> the v4 patch.  It means that future hot elog/ereport calls should make
> it into the cold path.

Something based on the v4 patch makes sense.

I would add DEBUG1 back into the conditional, like

if (__builtin_constant_p(elevel) && ((elevel) >= ERROR || (elevel) <= 
DEBUG1) ? \

Also, for the __has_attribute handling, I'd prefer the style that Andres 
illustrated earlier, using:

#ifndef __has_attribute
#define __has_attribute(attribute) 0
#endif

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Commits

  1. Stop gap fix for __attribute__((cold)) compiler bug in MinGW 8.1

  2. Tidy up definitions of pg_attribute_hot and pg_attribute_cold

  3. Fix unportable usage of __has_attribute

  4. Improve compiler code layout in elog/ereport ERROR calls

  5. Define pg_attribute_cold and pg_attribute_hot macros