Content-Type: multipart/mixed; boundary="------------tO07Ts5MzAV7Scwq6Q3jVTHb"
Message-ID: <1cb0d7e9-d6dd-4517-a7cd-0ad98e1207f3@iki.fi>
Date: Tue, 10 Feb 2026 19:14:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons
 from procsignals)
To: Andres Freund <andres@anarazel.de>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
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>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: <aYtcMg5hMdGdhX4q@alap3.anarazel.de>
Archived-At: 
 <https://www.postgresql.org/message-id/1cb0d7e9-d6dd-4517-a7cd-0ad98e1207f3%40iki.fi>
Precedence: bulk

This is a multi-part message in MIME format.
--------------tO07Ts5MzAV7Scwq6Q3jVTHb
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

(moving to pgsql-hackers)

On 10/02/2026 18:41, Andres Freund wrote:
> On 2026-02-10 17:52:16 +0200, Heikki Linnakangas wrote:
>> If there's a performance reason to keep have it be aligned - and maybe there
>> is - we should pad it explicitly.
> 
> We should make it a power of two or such. There are some workloads where the
> indexing from GetPGProcByNumber() shows up, because it ends up having to be
> implemented as a 64 bit multiplication, which has a reasonably high latency
> (3-5 cycles). Whereas a shift has a latency of 1 and typically higher
> throughput too.

Power of two means going to 1024 bytes. That's a lot of padding. Where 
have you seen that show up?

Attached is a patch to align to cache line boundary. That's 
straightforward if that's what we want to do.

> Re false sharing: We should really separate stuff that changes (like
> e.g. pendingRecoveryConflicts) and never changing stuff (backendType). You
> don't need overlapping structs to have false sharing issues if you mix
> different access patterns inside a struct that's accessed across processes...

Makes sense, although I don't want to optimize too hard for performance, 
at the expense of readability. The current order is pretty random 
anyway, though.

It'd probably be good to move the subxids cache to the end of the 
struct. That'd act as natural padding, as it's not very frequently used, 
especially the tail end of the cache. Or come to think of it, it might 
be good to move the subxids cache out of PGPROC altogether. It's mostly 
frequently accessed in GetSnapshotData(), and for that it'd actually be 
better if it was in a separate "mirrored" array, similar to the main xid 
and subxidStates. That would eliminate the pgprocnos[pgxactoff] lookup 
from GetSnapshotdata() altogether.

I'm a little reluctant to mess with this without a concrete benchmark 
though. Got one in mind?

- Heikki

--------------tO07Ts5MzAV7Scwq6Q3jVTHb
Content-Type: text/x-patch; charset=UTF-8;
 name="0001-Align-PGPROC-to-cache-line-boundary.patch"
Content-Disposition: attachment;
 filename="0001-Align-PGPROC-to-cache-line-boundary.patch"
Content-Transfer-Encoding: base64

RnJvbSBhM2UyZDk0ZjZhM2FiMjE1YWZkM2U4Y2VlNjI0YmQ5YzA5ZWM1MzkxIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBIZWlra2kgTGlubmFrYW5nYXMgPGhlaWtraS5saW5u
YWthbmdhc0Bpa2kuZmk+CkRhdGU6IFR1ZSwgMTAgRmViIDIwMjYgMTg6NTM6MzEgKzAyMDAK
U3ViamVjdDogW1BBVENIIDEvMV0gQWxpZ24gUEdQUk9DIHRvIGNhY2hlIGxpbmUgYm91bmRh
cnkKCi0tLQogc3JjL2luY2x1ZGUvc3RvcmFnZS9wcm9jLmggfCAxNiArKysrKysrKysrKyst
LS0tCiAxIGZpbGUgY2hhbmdlZCwgMTIgaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkK
CmRpZmYgLS1naXQgYS9zcmMvaW5jbHVkZS9zdG9yYWdlL3Byb2MuaCBiL3NyYy9pbmNsdWRl
L3N0b3JhZ2UvcHJvYy5oCmluZGV4IGFjMGRmNGFlYWFhLi41M2FjY2U4YTVhMSAxMDA2NDQK
LS0tIGEvc3JjL2luY2x1ZGUvc3RvcmFnZS9wcm9jLmgKKysrIGIvc3JjL2luY2x1ZGUvc3Rv
cmFnZS9wcm9jLmgKQEAgLTE4Miw3ICsxODIsNyBAQCB0eXBlZGVmIGVudW0KICAqCiAgKiBT
ZWUgUFJPQ19IRFIgZm9yIGRldGFpbHMuCiAgKi8KLXN0cnVjdCBQR1BST0MKK3R5cGVkZWYg
c3RydWN0IFBHUFJPQwogewogCWRsaXN0X25vZGUJbGlua3M7CQkJLyogbGlzdCBsaW5rIGlm
IHByb2Nlc3MgaXMgaW4gYSBsaXN0ICovCiAJZGxpc3RfaGVhZCAqcHJvY2dsb2JhbGxpc3Q7
IC8qIHByb2NnbG9iYWwgbGlzdCB0aGF0IG93bnMgdGhpcyBQR1BST0MgKi8KQEAgLTMzNywx
MCArMzM3LDE4IEBAIHN0cnVjdCBQR1BST0MKIAlQR1BST0MJICAgKmxvY2tHcm91cExlYWRl
cjsJLyogbG9jayBncm91cCBsZWFkZXIsIGlmIEknbSBhIG1lbWJlciAqLwogCWRsaXN0X2hl
YWQJbG9ja0dyb3VwTWVtYmVyczsJLyogbGlzdCBvZiBtZW1iZXJzLCBpZiBJJ20gYSBsZWFk
ZXIgKi8KIAlkbGlzdF9ub2RlCWxvY2tHcm91cExpbms7CS8qIG15IG1lbWJlciBsaW5rLCBp
ZiBJJ20gYSBtZW1iZXIgKi8KLX07Ci0KLS8qIE5PVEU6ICJ0eXBlZGVmIHN0cnVjdCBQR1BS
T0MgUEdQUk9DIiBhcHBlYXJzIGluIHN0b3JhZ2UvbG9jay5oLiAqLworfQogCisvKgorICog
SWYgY29tcGlsZXIgdW5kZXJzdGFuZHMgYWxpZ25lZCBwcmFnbWEsIHVzZSBpdCB0byBhbGln
biB0aGUgc3RydWN0IGF0IGNhY2hlCisgKiBsaW5lIGJvdW5kYXJpZXMuICBUaGlzIGlzIGp1
c3QgZm9yIHBlcmZvcm1hbmNlLCB0byAoYSkgYXZvaWQgZmFsc2Ugc2hhcmluZworICogYW5k
IChiKSB0byBtYWtlIHRoZSBtdWx0aXBsaWNhdGlvbiAvIGRpdmlzaW9uIHRvIGNvbnZlcnQg
YmV0d2VlbiBQR1BST0MgKgorICogYW5kIFByb2NOdW1iZXIgYmUgYSBsaXR0bGUgY2hlYXBl
ci4KKyAqLworI2lmIGRlZmluZWQocGdfYXR0cmlidXRlX2FsaWduZWQpCisJCQlwZ19hdHRy
aWJ1dGVfYWxpZ25lZChQR19DQUNIRV9MSU5FX1NJWkUpCisjZW5kaWYKK1BHUFJPQzsKIAog
ZXh0ZXJuIFBHRExMSU1QT1JUIFBHUFJPQyAqTXlQcm9jOwogCi0tIAoyLjQ3LjMKCg==

--------------tO07Ts5MzAV7Scwq6Q3jVTHb--