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

Re: Initial 9.2 pgbench write results

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Initial 9.2 pgbench write results
Date: 2012-02-28 17:25:13
Message-ID: CA+TgmoYTbxi91AxRbP++sC=PwTF_1w6iqd7-1AvGzO73HfXOaw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Feb 28, 2012 at 11:36 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> How hard would it be to dummy up a bgwriter which, every time it wakes
> up, it forks off a child process to actually do the write, and then
> the real one just waits for the child to exit?  If it didn't have to
> correctly handle signals, SINVAL, and such, it should be just a few
> lines of code, but I don't know how much we can ignore signals and
> such even just for testing purposes.  My thought here is that the
> kernel is getting in a snit over one process doing all the writing on
> the system, and is punishing that process in a way that ruins things
> for everyone.

I would assume the only punishment that the kernel would inflict would
be to put the bgwriter to sleep.  That would make the bgwriter less
effective, of course, but it shouldn't make it worse than no bgwriter
at all.  Unless it does it some really stupid way, like making
bgwriter sleep while it holds some lock.

But maybe I'm missing something - what do you have in mind?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: karavelovDate: 2012-02-28 17:27:45
Subject: Re: Initial 9.2 pgbench write results
Previous:From: Pavel StehuleDate: 2012-02-28 16:49:11
Subject: strange plan - PostgreSQL 9.2

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