On 2015-01-27 10:36:35 -0500, Robert Haas wrote: > On Mon, Jan 26, 2015 at 11:20 PM, Robert Haas <robertmh...@gmail.com> wrote: > > This developed a slight merge conflict. I've rebased the attached > > version, and I also took the step of getting rid of buf_table.c, as I > > think I proposed somewhere upthread. This avoids the overhead of > > constructing a BufferTag only to copy it into a BufferLookupEnt, plus > > some function calls and so forth. A quick-and-dirty test suggests > > this might not have cut down on the 1-client overhead much, but I > > think it's worth doing anyway: it's certainly saving a few cycles, and > > I don't think it's complicating anything measurably. > > So here are median-of-three results for 5-minute read-only pgbench > runs at scale factor 1000, shared_buffers = 8GB, on hydra (POWER7) at > various client counts.
> That's extremely unimpressive. You (Andres) showed a much bigger > benefit on a different machine with a much higher scale factor (5000) > so I don't know whether the modest benefit here is because of the > different machine, the different scale factor, or what. Based on my test on hydra some time back the bottleneck is nearly entirely in GetSnapshotData() at higher client counts. So I'm not that surprised you don't see the big benefit here. IIRC on hydra the results for using a large enough shared_buffers setting for a fully cached run at that scale is pretty close to your master results - so there's really not much performance increase to be expected by making the buf table lockless. I guess you would see a slightly bigger difference at a different shared_buffer/scale combination. IIRC a scale 1000 is about 15GB large? So about half of the data set fit in shared buffers. In the scale 5k results I posted it was about 1/5. I had also tested on a four socket x86 machine where GetSnapshotData() was a, but not the sole big, bottleneck. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
