Re: sorted writes for checkpoints

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sorted writes for checkpoints
Date: 2010-10-29 14:22:48
Message-ID: 1020.1288362168@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> Simon's argument in the thread that the todo item points to
> (http://archives.postgresql.org/pgsql-patches/2008-07/msg00123.php) is
> basically that we don't know what the best algorithm is yet and
> benchmarking is a lot of work, so let's just let people do whatever they
> feel like until we settle on the best approach. I think we need to bite
> the bullet and do some benchmarking, and commit one carefully vetted
> patch to the backend.

Yeah, I tend to agree. We've used hooks in the past to allow people to
add on non-critical functionality. Fooling with the behavior of
checkpoints is far from noncritical. Furthermore, it's really hard to
see what a sane hook API would even look like. As Robert comments,
part of any win here would likely come from controlling the timing of
fsyncs, not just writes. Controlling all that at arm's length from
the code that actually does it seems likely to be messy and inefficient.

Another point is that I don't see any groundswell of demand out there
for custom checkpoint algorithms. If we did manage to create a hook
API, how likely is it there would ever be more than one plugin?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-10-29 15:23:38 Re: plan time of MASSIVE partitioning ...
Previous Message Robert Haas 2010-10-29 13:17:16 Re: sorted writes for checkpoints