Re: Checkpointer split has broken things dramatically (was Re: DELETE vs TRUNCATE explanation)

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Peter Geoghegan <peter@2ndquadrant.com>
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-18T07:30:40Z
Lists: pgsql-hackers, pgsql-performance
On 18.07.2012 02:48, Peter Geoghegan wrote:
> On 17 July 2012 23:56, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>> 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.
>
> The checkpointer slit-up was not justified as a performance
> optimisation so much as a re-factoring effort that might have some
> concomitant performance benefits.

Agreed, but it means that we need to re-run the tests that were done to 
make sure the extra fsync-request traffic is not causing a performance 
regression, 
http://archives.postgresql.org/pgsql-hackers/2011-10/msg01321.php.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Scan the buffer pool just once, not once per fork, during relation drop.