Re: Checkpointer split has broken things dramatically (was
Re: DELETE vs TRUNCATE explanation)
From:
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To:
Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc:
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Farina <daniel(at)heroku(dot)com>, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>, "Harold A(dot) Giménez" <harold(dot)gimenez(at)gmail(dot)com>
Subject:
Re: Checkpointer split has broken things dramatically (was
Re: DELETE vs TRUNCATE explanation)
On 18.07.2012 02:48, Peter Geoghegan wrote:
> On 17 July 2012 23:56, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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
