On Mon, Jan 17, 2011 at 8:23 PM, Greg Smith <greg@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'llnever 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
