public inbox for [email protected]  

help / color / mirror / Atom feed

From: Andres Freund <[email protected]>
To: Bertrand Drouvot <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
Date: Tue, 10 Feb 2026 14:46:31 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Hi,

On 2026-02-10 19:15:27 +0000, Bertrand Drouvot wrote:
> On Tue, Feb 10, 2026 at 01:15:01PM -0500, Andres Freund wrote:
> > On 2026-02-10 19:14:44 +0200, Heikki Linnakangas wrote:
> > Yea, I don't think we need to be perfect here. Just a bit less bad. And, as
> > you say, the current order doesn't make a lot of sense.
> > Just grouping things like
> > - pid, pgxactoff, backendType (i.e. barely if ever changing)
> > - wait_event_info, waitStart (i.e. very frequently changing, but typically
> >   accessed within one proc)
> > - sem, lwWaiting, waitLockMode (i.e. stuff that is updated frequently and
> >   accessed across processes)
> 
> With an ordering like in the attached (to apply on top of Heikki's patch), we're
> back to 832 bytes.

You'd really need to insert padding between the sections to make it work...


> But, then the pg_attribute_aligned() added in Heikki's patch makes it 896 bytes...
> 
> "
> /*    816      |      16 */    dlist_node lockGroupLink;
> /* XXX 64-byte padding   */
> 
>                                /* total size (bytes):  896 */
>                              }
> "
> 
> What about applying this new ordering and remove the pg_attribute_aligned()?


> (I thought the aligned attribute would be smarter than that and not add this
> 64 padding bytes).

That's just because we have

/*
 * Assumed cache line size.  This doesn't affect correctness, but can be used
 * for low-level optimizations.  This is mostly used to pad various data
 * structures, to ensure that highly-contended fields are on different cache
 * lines.  Too small a value can hurt performance due to false sharing, while
 * the only downside of too large a value is a few bytes of wasted memory.
 * The default is 128, which should be large enough for all supported
 * platforms.
 */
#define PG_CACHE_LINE_SIZE		128


I don't think we need to worry about the number of bytes here very much. This
isn't much compared to all the other overheads a connection slot has (like the
memory for locks).

Greetings,

Andres Freund

view thread (22+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox