From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sinval synchronization considered harmful |
Date: | 2011-07-29 04:37:20 |
Message-ID: | CA+TgmoaAAB4Jby0=H+jdKUeek63THOq40_iH0Wxk4FrLa3jw6g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 28, 2011 at 11:05 PM, Noah Misch <noah(at)2ndquadrant(dot)com> wrote:
> 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.
Me, too. There's another possible benefit, though: in
sinval-fastpath, everybody's got to read maxMsgNum every time through;
whereas in sinval-hasmessages, everyone's reading their own flag. I'm
not sure how much it costs to have memory that gets read by multiple
readers rather than just a single reader, but I think I've seen some
things that indicate it might not always be free.
> 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.
Wow. That's better than I expected. Great idea for a test, too.
Unless someone has another concern here, I think we've got this one nailed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | daveg | 2011-07-29 06:31:31 | Re: error: could not find pg_class tuple for index 2662 |
Previous Message | Noah Misch | 2011-07-29 03:05:15 | Re: sinval synchronization considered harmful |