On 31 January 2012 14:24, Robert Haas <robertmh...@gmail.com> wrote:
> I think you're trying to muddy the waters.  Heikki's implementation
> was different than yours, and there are some things about it I'm not
> 100% thrilled with, but it's fundamentally the same concept.  The new
> idea you're describing here is something else entirely.  Instead of
> focusing on a technical critique of one implementation vs. another
> (out of the three we have to choose from), you're looking at cramming
> more optimizations into the implementation you prefer.  I'm pretty
> sure that Heikki's implementation could support that optimization,
> too, if we actually want to do it that way.  But there might be good
> reasons not to do it that way: for example, every transaction commit
> will have to bump the CLOG page LSN, which will delay setting hint
> bits on other transactions on the page in cases where they can now be
> set immediately.  In any event, trying to slip it into the group
> commit patch will serve only to prevent it from getting the separate
> scrutiny which it doubtless deserves.

Well, I also think it deserves separate scrutiny, but it's not as if
it can be reasonably argued that it can be isolated from 1 of those 3
implementations. Our immediate goal is to produce a benchmark of a new
patch, that operates on the same fundamental principle as the original
patch, though with a much reduced code footprint. We then have a
reasonable basis for comparison: The original benchmark (or possibly a
new benchmark on the original patch, which has seemingly identical
performance characteristics to Heikki's anyway), and the new patch.

Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to