On Thu, Jul 28, 2011 at 11:05 PM, Noah Misch <noah@2ndquadrant.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