Re: SSI non-serializalbe UPDATE performance (was: getting to beta)

> Dan Ports  wrote:
> Even under these conditions I couldn't reliably see a slowdown. My
> latest batch of results (16 backends, median of three 10 minute
> runs) shows a difference well below 1%. In a couple of cases I saw
> the code with the SSI checks running faster than with them removed,
> so this difference seems in the noise.
Now that Dan has finished the comparative performance tests, and the
version with SSI sometimes tests faster, sometimes slower, with the
difference always a fraction of a percent even on a fairly unusual
worst case environment (tmpfs and dataset fits in cache buffers), I
think we can take this off the 9.1 "must fix" list.  We've seen much
larger changes with no explanation other than an assumption that the
executable code heppens to line up on line cache boundaries
differently.
Unless there is an objection, I'll move this item from "Blockers for
Beta1" to "Not Blockers for Beta1" on the Wiki page, pending results
of the point raised below.
> we might as well bail out of these functions early if there are no
> serializable transactions running. Kevin points out we can do this
> by checking if PredXact->SxactGlobalXmin is invalid. I would add
> that we can do this safely without taking any locks, even on
> weak-memory-ordering machines. Even if a new serializable
> transaction starts concurrently, we have the appropriate buffer
> page locked, so it's not able to take any relevant SIREAD locks.
Even though this didn't show any difference in Dan's performance
tests, it seems like reasonable insurance against creating a new
bottleneck in very high concurrency situations.
Dan, do you have a patch for this, or should I create one?
-Kevin