On 28 June 2012 20:00, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers