Horton
Menu

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

Craig Ringer <ringerc@ringerc.id.au>

View thread
From: Craig Ringer <ringerc@ringerc.id.au>
To: Greg Smith <greg@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>, "Harold A. Giménez" <harold.gimenez@gmail.com>
Date: 2012-07-18T04:20:39Z
Lists: pgsql-hackers, pgsql-performance 
On 07/18/2012 12:00 PM, Greg Smith wrote:

> The second justification for the split was that it seems easier to get 
> a low power result from, which I believe was the angle Peter Geoghegan 
> was working when this popped up originally.  The checkpointer has to 
> run sometimes, but only at a 50% duty cycle as it's tuned out of the 
> box.  It seems nice to be able to approach that in a way that's power 
> efficient without coupling it to whatever heartbeat the BGW is running 
> at.  I could even see people changing the frequencies for each 
> independently depending on expected system load.  Tune for lower power 
> when you don't expect many users, that sort of thing.
>
Yeah - I'm already seeing benefits from that on my laptop, with much 
less need to stop Pg when I'm not using it.

--
Craig Ringer

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.