On Wed, Apr 20, 2016 at 8:08 PM, Ants Aasma <
ants.aasma@eesti.ee> wrote:
> I had an idea I wanted to test out. The gist of it is to effectively
> have the last slot of timestamp to xid map stored in the latest_xmin
> field and only update the mapping when slot boundaries are crossed.
> See attached WIP patch for details. This way the exclusive lock only
> needs to be acquired once per minute. The common case is a spinlock
> that could be replaced with atomics later.
I rebased the patch Ants posted (attached), and am running
benchmarks on a cthulhu (a big NUMA machine with 8 memory nodes).
Normally I wouldn't post results without a lot more data points
with multiple samples at each, but the initial results have me
wondering whether people would like to see this pushed later today
so that it has some time in the buildfarm and then into beta1.
Running the r/w TPC-B (sort of) load with scale, jobs, and threads
at 1000, and the database configured as I would for a production
server of that size, preliminary TPS results are:
master, -1: 8158
master, 10min: 2019
Ants' patch, 10min: 7804
Basically it just skips the maintenance of the time/xid mapping
unless current time has advanced to a new minute.
I can see arguments for tuning this far in time for the beta, as
well as the argument to wait until after the beta, so I'm just
throwing it out there to see what other people think. I wouldn't
do it unless I have three runs at -1 and 10min with the patch, all
showing similar numbers. If the BF chokes on it I would revert
this optimization attempt.
Thoughts?
--
Kevin Grittner
EDB:
http://www.enterprisedb.comThe Enterprise PostgreSQL Company