Skip site navigation (1) Skip section navigation (2)

Re: sorted writes for checkpoints

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: sorted writes for checkpoints
Date: 2010-10-29 06:23:43
Message-ID: 4CCA686F.40800@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 29.10.2010 06:00, Jeff Janes wrote:
> One of the items on the Wiki ToDo list is sorted writes for
> checkpoints.  The consensus seemed to be that this should be done by
> adding hook(s) into the main code, and then a contrib module to work
> with those hooks.  Is there an existing contrib module that one could
> best look to for inspiration on how to go about doing this?  I have
> the sorted checkpoint working under a guc, but don't know where to
> start on converting it to a contrib module instead.

I don't think it's a good idea to have this as a hook. Bgwriter 
shouldn't need to load external code, and checkpoint robustness should 
dependend on user-written code. IIRC Tom Lane didn't even like pallocing 
the memory for the list of dirty pages at checkpoint time because that 
might cause an out-of-memory error. Calling a function in a contrib 
module is much much worse.

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.

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

In response to

Responses

pgsql-hackers by date

Next:From: Itagaki TakahiroDate: 2010-10-29 06:58:58
Subject: Re: sorted writes for checkpoints
Previous:From: Tom LaneDate: 2010-10-29 06:08:34
Subject: Re: plan time of MASSIVE partitioning ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group