Skip site navigation (1) Skip section navigation (2)

Re: Group commit, revised

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Group commit, revised
Date: 2012-01-31 14:44:19
Message-ID: CAEYLb_W9xpVO-qxLiWDU3-7UDFzMBTVEX-zMeAfJBXUDYuFzoQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 31 January 2012 14:24, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

pgsql-hackers by date

Next:From: Yeb HavingaDate: 2012-01-31 15:27:08
Subject: Re: [v9.2] Add GUC sepgsql.client_label
Previous:From: Merlin MoncureDate: 2012-01-31 14:35:03
Subject: Re: JSON for PG 9.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group