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

Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Date: 2012-06-28 19:17:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 28 June 2012 20:00, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> See VACUUM FULL for a recent counterexample --- we basically jacked it
> up and drove a new implementation underneath, but we didn't change the
> name, despite the fact that we were obsoleting a whole lot more folk
> knowledge than exists around commit_delay.
> Of course, there were application-compatibility reasons not to rename
> that command, which wouldn't apply so much to commit_delay.  But still,
> we have precedent for expecting that we can fix external documentation
> rather than trying to code around whatever it says.

I'm sure you're right to some degree. We can rely on some, maybe even
most users to go and learn about these things, or hear about them
somehow. But why should we do it that way, when what I've proposed is
so much simpler, and has no plausible downside?

Here, you say:

The issue here is not "is group commit a good idea in the abstract?".
It is "is the commit_delay implementation of the idea worth a dime?"
... and the evidence we have all points to the answer "NO".  We should
not let theoretical arguments blind us to this.

What happens when someone reads this, or many other such statements
were made before or since, when they are considering setting
commit_delay now?

The VACUUM FULL implementation is now very close to being nothing more
than a synonym of CLUSTER. The only reason it happened that way was
because it was easier than just deprecating VACUUM FULL. The old
VACUUM FULL actually had something to recommend it. It seems unlikely
that the same thing can be said for commit_delay.

Peter Geoghegan
PostgreSQL Development, 24x7 Support, Training and Services

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2012-06-28 19:46:50
Subject: Re: Posix Shared Mem patch
Previous:From: Josh BerkusDate: 2012-06-28 19:03:15
Subject: Re: We probably need autovacuum_max_wraparound_workers

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