Hello hackers,
While working on two phase related issues, I found something related to two
phase could be optimized.
1. The current implementation decouples PREPRE and COMMIT/ABORT PREPARE a lot.
This is flexible, but if
PREPARE & COMMIT/ABORT mostly happens on the same backend we could use the
cache mechanism to
speed up, e.g.
a. FinishPreparedTransaction()->LockGXact(gid, user)
for (i = 0; i < TwoPhaseState->numPrepXacts; i++)
find the gxact that matches gid
For this we can cache the gxact during PREPARE and use that for a
fast path, i.e. if the cached gxact
matches gid we do not need to walk through the gxact array. By the
way, if the gxact array is large this
will be a separate performance issue (use shared-memory hash table if
needed?).
b. FinishPreparedTransaction() reads the PREPARE information from either
state file (stored during checkpoint)
or wal file. We could cache the content during PREPARE, i.e. in
EndPrepare() then in FinishPreparedTransaction()
we can avoid reading the state file or the wal file.
It is possible that some databases based on Postgres two phase might not
want the cache, e.g. if PREPARE
backend is always different than the COMMIT/ABORT PREPARE backend (I do
not know what database is
designing like this though), but gxact caching is almost no overhead and
for b we could use ifdef to guard the
PREPARE wal data copying code.
The two optimizations are easy and small. I've verified on Greenplum
database (based on Postgres 12).
2. wal content duplication between PREPARE and COMMT/ABORT PREPARE
See the below COMMIT PREPARE function call. Those hdr->* have existed in
PREPARE wal also. We do
not need them in the COMMIT PREPARE wal also. During recovery, we could
load these information (both
COMMIT and ABORT) into memory and in COMMIT/ABORT PREPARE redo we use the
corresponding data.
RecordTransactionCommitPrepared(xid,
hdr->nsubxacts, children,
hdr->ncommitrels, commitrels,
hdr->ninvalmsgs, invalmsgs,
hdr->initfileinval, gid);
One drawback of the change is this might involve non-trivial change.
3. About gid, current gid is defined as a char[]. I'm wondering if we should
define an opaque type and let some
Databases implement their own gid types using callbacks. Typically if I
want to use 64-bit distributed xid as gid,
current code is not that performance & storage friendly (e.g. still need to
use strcmp to find gxact in LockGXact,).
We may implement a default implementation as char[]. gid is not widely used
so the change seems to
be small (interfaces of copy, comparison, conversion from string to
internal gid type for the PREPARE statement, etc)
Any thoughts?
Regards,
Paul
