Two things.
1. We use a hash table in shared memory. That's great. The part that's
not so great is that in both places where we read items from it, we
have to iterate in some way. This seems a bit silly. An array would
serve us better, if only we could expand it as needed. However, in
shared memory we can't do that. (I think the list of elements we
need to memoize is arbitrary long, if enough processes can be writing
WAL at the same time.)
Now that I think about this again, maybe it's limited by
NUM_XLOGINSERT_LOCKS, since there can only be that many records being
written down at a time ...
2. There is a new LWLock acquisition that may be a new contention point.
We acquire the lock in these cases:
- WAL record insert, when a segment boundary is crosses (rare
enough).
- XLogWrite, when a segment needs to be notified.
Looking again, I think the last point might be a problem actually,
because XLogWrite is called with WALWriteLock held. Maybe we should
take the NotifySegmentsReadyForArchive() call outside the section
locked by WALWriteLock (so put it in XLogWrite callers instead of
XLogWrite itself).
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar
al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en
La Feria de las Tinieblas, R. Bradbury)