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

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?

http://archives.postgresql.org/pgsql-hackers/2005-06/msg01463.php

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       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services