Re: [PERFORM] In progress INSERT wrecks plans on table

At 2013-07-12 16:25:14 -0700, jeff(dot)janes(at)gmail(dot)com wrote:
>
> I think the reviewer of a performance patch should do some independent
> testing of the performance, to replicate the author's numbers; and
> hopefully with a few different scenarios.

You're quite right. I apologise for being lazy; doubly so because I
can't actually see any difference while running the test case with
the patches applied.

unpatched:
before: 1629.831391, 1559.793758, 1498.765018, 1639.384038
during: 37.434492, 37.044989, 37.112422, 36.950895
after : 46.591688, 46.341256, 46.042169, 46.260684

patched:
before: 1813.091975, 1798.923524, 1629.301356, 1606.849033
during: 37.344987, 37.207359, 37.406788, 37.316925
after : 46.657747, 46.537420, 46.746377, 46.577052

("before" is before starting session 2; "during" is after session 2
inserts, but before it commits; "after" is after session 2 issues a
rollback.)

The timings above are with both xid_in_snapshot_cache.v1.patch and
cache_TransactionIdInProgress.v2.patch applied, but the numbers are
not noticeably different with only the first patch applied. After I
"vacuum plan", the timings in both cases return to normal.

In a quick test with gdb (and also in perf report output), I didn't see
the following block in procarray.c being entered at all:

+ if (max_prepared_xacts == 0 && pgprocno >= 0 &&
+ (TransactionIdEquals(xid, pxid) || TransactionIdEquals(xid, cxid)))
+ {
…

I'll keep looking, but comments are welcome. I'm setting this back to
"Needs Review" in the meantime.

-- Abhijit