Re: sinval synchronization considered harmful

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