From: | karavelov(at)mail(dot)bg |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Initial 9.2 pgbench write results |
Date: | 2012-02-28 17:27:45 |
Message-ID: | c1422856c3cb6bbd40ac27630b1c714f.mailbg@beta.mail.bg |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
----- Цитат от Robert Haas (robertmhaas(at)gmail(dot)com), на 28.02.2012 в 19:25 -----
> 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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
--
Luben Karavelov
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-02-28 17:49:06 | Re: Initial 9.2 pgbench write results |
Previous Message | Robert Haas | 2012-02-28 17:25:13 | Re: Initial 9.2 pgbench write results |