Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)
David Fetter <david@fetter.org>
From: David Fetter <david@fetter.org>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, 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-23T12:41:23Z
Lists: pgsql-hackers, pgsql-performance
On Mon, Jul 23, 2012 at 08:29:16AM -0400, Andrew Dunstan wrote: > > On 07/23/2012 12:37 AM, David Fetter wrote: > >On Tue, Jul 17, 2012 at 06:56:50PM -0400, Tom Lane wrote: > >>Robert Haas <robertmhaas@gmail.com> writes: > >>>On Mon, Jul 16, 2012 at 3:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >>>>BTW, while we are on the subject: hasn't this split completely > >>>>broken the statistics about backend-initiated writes? > >>>Yes, it seems to have done just that. > >>This implies that nobody has done pull-the-plug testing on either > >>HEAD or 9.2 since the checkpointer split went in (2011-11-01), > >>because even a modicum of such testing would surely have shown that > >>we're failing to fsync a significant fraction of our write traffic. > >> > >>Furthermore, I would say that any performance testing done since > >>then, if it wasn't looking at purely read-only scenarios, isn't > >>worth the electrons it's written on. In particular, any performance > >>gain that anybody might have attributed to the checkpointer splitup > >>is very probably hogwash. > >> > >>This is not giving me a warm feeling about our testing practices. > >Is there any part of this that the buildfarm, or some other automation > >framework, might be able to handle? > > > > I'm not sure how you automate testing a pull-the-plug scenario. I have a dim memory of how the FreeBSD project was alleged to have done it, namely by rigging a serial port (yes, it was that long ago) to the power supply of another machine and randomly cycling the power. > The buildfarm is not at all designed to test performance. That's why > we want a performance farm. Right. Apart from hardware, what are we stalled on? Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
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