On Thu, Jul 28, 2011 at 11:05 PM, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
