> On October 3, 2018 at 3:55 PM Andres Freund <andres@anarazel.de> wrote:
> In the thread around https://www.postgresql.org/message-id/20160411214029.ce3fw6zxim5k6a2r@alap3.anarazel.de
> I'd found doing more aggressive padding helped a lot. Unfortunately I
> didn't pursue this further :(
Interesting. Looks like you saw the same thing I see now.
> I really suspect we're going to have to change the layout of PGXACT data
> in a way that makes a contiguous scan possible. That'll probably require
> some uglyness because a naive "use first free slot" scheme obviously is
> sensitive to there being holes. But I suspect that a scheme were
> backends would occasionally try to move themselves to an earlier slot
> wouldn't be too hard to implement.
I've also thought of this. But someone could create a thousand connections and
then disconnect all but the first and last creating a huge hole. One thought
would be to have a bit array of used entries and to bias toward using free lower
indexed entries. Only two cache lines of 1024 bits would need to be scanned to
handle 1024 connections. ProcArrayAdd() would just do an atomic xchg to set the
used bit.
I was even thinking of decomposing PGXACT into separate arrays of XID's, XMIN's,
etc. Then have a bit map of those entries where the XID was valid. When you
set/clear your XID you'd also set/clear this bit. With the select only workload
the XID are all "Invalid" thus scanning this bit array of zeroed 64 bit long entries
would be quite efficient. The vacuum and logical decoding flags could be directly
done as a bit map. Having a array of 1 byte subtxn counts creates another
opportunity for improvement. Scanning for a non-zero in env's which use few
subtxn's is efficient. If subtxn's are used a lot then the repeated PGXACT
cache line invalidations when setting nxids is offset by the fact that you can
grab 8 of them in a single fetch.
- Dan
