Feedback-ID: id4a34324:Fastmail
Date: Tue, 10 Feb 2026 14:46:31 -0500
From: Andres Freund <andres@anarazel.de>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: PGPROC alignment (was Re: pgsql: Separate
 RecoveryConflictReasons from procsignals)
Message-ID: <aYuIrKbh1kW36xbc@alap3.anarazel.de>
References: <E1vpon6-002LVp-2z@gemulon.postgresql.org>
 <aYtMbb28qxqLrhvC@ip-10-97-1-34.eu-west-3.compute.internal>
 <a6159474-a06b-4874-9e4f-f06516995860@iki.fi>
 <aYtcMg5hMdGdhX4q@alap3.anarazel.de>
 <1cb0d7e9-d6dd-4517-a7cd-0ad98e1207f3@iki.fi>
 <aYtsrQ-kmA8nqeiH@alap3.anarazel.de>
 <aYuDz2kvi7haNORb@ip-10-97-1-34.eu-west-3.compute.internal>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aYuDz2kvi7haNORb@ip-10-97-1-34.eu-west-3.compute.internal>
Archived-At: 
 <https://www.postgresql.org/message-id/aYuIrKbh1kW36xbc%40alap3.anarazel.de>
Precedence: bulk

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