On Mon, Jan 17, 2011 at 8:23 PM, Greg Smith <g...@2ndquadrant.com> wrote: > Quite. It's taken me 12 days of machine time running pgbench to find the > spots where this problem occurs on a system with a reasonably sized > shared_buffers (I'm testing against 256MB). It's one of those things it's > hard to reproduce with test data. > > Thanks for the thorough code review. I've got a clear test plan I'm > progressing through this week to beat on the performance measurement aspects > of the patch.
Any update on this? I think the test results you've posted previously - particularly, the fact that when the queue fills up, there are always many duplicates - is pretty much sufficient for us to convince ourselves that this will provide a benefit in cases where that occurs. And, in cases where the queue doesn't fill up, we'll never hit the test that triggers this code, so it seems pretty clear there won't be a negative impact there either. I don't want to rush your testing process, but if it's already fairly clear that this will have some benefit, I think it would be good to get it committed and move on to working on the parts we're less sure about, like sorting writes and spreading fsyncs, where we will probably need a lot more testing than here to be sure that we have the right behavior. -- 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
