Re: [PERFORM] DELETE vs TRUNCATE explanation
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Daniel Farina <daniel@heroku.com>, Craig Ringer <ringerc@ringerc.id.au>, Harold A. Giménez <harold.gimenez@gmail.com>
Date: 2012-07-16T19:03:03Z
Lists: pgsql-hackers, pgsql-performance
Robert Haas <robertmhaas@gmail.com> writes: > Unfortunately, there are lots of important operations (like bulk > loading, SELECT * FROM bigtable, and VACUUM notverybigtable) that > inevitably end up writing out their own dirty buffers. And even when > the background writer does write something, it's not always clear that > this is a positive thing. Here's Greg Smith commenting on the > more-is-worse phenonmenon: > http://archives.postgresql.org/pgsql-hackers/2012-02/msg00564.php > Jeff Janes and I came up with what I believe to be a plausible > explanation for the problem: > http://archives.postgresql.org/pgsql-hackers/2012-03/msg00356.php > I kinda think we ought to be looking at fixing that for 9.2, and > perhaps even back-patching further, but nobody else seemed terribly > excited about it. I'd be fine with back-patching something like that into 9.2 if we had (a) a patch and (b) experimental evidence that it made things better. Unless I missed something, we have neither. Also, I read the above two messages to say that you, Greg, and Jeff have three different ideas about exactly what should be done, which is less than comforting for a last-minute patch... regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Scan the buffer pool just once, not once per fork, during relation drop.
- ece01aae4792 9.2.0 cited