Re: sinval synchronization considered harmful - Mailing list pgsql-hackers

On Thu, Jul 28, 2011 at 03:03:05PM -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 10:05 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> >> I'll also test out creating and dropping some tables.
> >
> > Still need to work on this one.
> 
> And there results are in.  I set up the following sophisticated test
> script for pgbench:
> 
> CREATE TEMP TABLE foo (a int);
> DROP TABLE foo;
> 
> And then did 5-minute test runs with varying numbers of clients on
> Nate Boley's 32-core machine with (a) master, (b) master +
> sinval-hasmessages, (c) master + lazy-vxid, and (d) master + lazy-vxid
> + sinval-hasmessages.

The comparison I had in mind was (a) master + lazy-vxid + [1]sinval-fastpath
vs. (b) master + lazy-vxid + [2]sinval-hasmessages.  The only claimed benefit of
[2] over [1], as far as I can see, is invulnerability to the hazard described in
[3].  Before selecting [2] over [1], it would be instructive to know how much
performance we exchange for its benefit.

I did a bit of (relatively unrigorous) poking at this workload with oprofile,
and I never saw SIInsertDataEntries take more than 0.26% of CPU time.  It's
perhaps too cheap relative to the workload's other costs to matter.  That's good
enough for me.

[1] http://archives.postgresql.org/message-id/CA+TgmoZc8Z_JTj44xvpWpXKQt2jGjB5YGCZ3T9u5-QZVdBmyCA@mail.gmail.com
[2] http://archives.postgresql.org/message-id/CA+TgmoZjo1bkP6eX=xOX3aHuPYbmJT9+PKW6qubQzN7sukK3Dg@mail.gmail.com
[3] http://archives.postgresql.org/message-id/20110727033537.GB18910@tornado.leadboat.com

> 80L tps = 1192.768020 (including connections establishing)
> 80L tps = 1165.545010 (including connections establishing)
> 80L tps = 1169.776066 (including connections establishing)

> 80LS tps = 1510.778084 (including connections establishing)
> 80LS tps = 1484.423486 (including connections establishing)
> 80LS tps = 1480.692051 (including connections establishing)

> 80 tps = 1154.272515 (including connections establishing)
> 80 tps = 1168.805881 (including connections establishing)
> 80 tps = 1173.971801 (including connections establishing)

> 80S tps = 1483.037788 (including connections establishing)
> 80S tps = 1481.059504 (including connections establishing)
> 80S tps = 1487.215748 (including connections establishing)
> 
> So, apparently, the extra work in SIInsertDataEntries() is more than
> paid for by the speedup in SIGetDataEntries().  I'm guessing that at
> high client counts you win because of reduced spinlock contention, and
> at low client counts you still win a little bit because
> SIGetDataEntries() is called multiple times per transaction, whereas
> SIInsertDataEntries() is only called once.  I could be all wet on the
> reason, but at any rate the numbers look pretty good.

Interesting.  I had hypothesized that at two clients per core, nearly every call
to SIGetDataEntries() would find work to do, making the patch a strict loss.  A
bit of instrumented testing showed otherwise: at two clients per core,
sinval-hasmessages optimized away 93% of the calls.  At fifty clients per core,
it still optimized away more than half of the calls.

-- 
Noah Misch                    http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services