On Wed, Apr 20, 2016 at 8:08 PM, Ants Aasma <ants.aa...@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.com The Enterprise PostgreSQL Company
update-old-snapshot-map-once-per-tick-v2.patch
Description: binary/octet-stream
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
