From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | mladen(dot)gogala(at)vmsinfo(dot)com |
Cc: | "wozniak(at)lanl(dot)gov" <wozniak(at)lanl(dot)gov>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: concurrent IO in postgres? |
Date: | 2010-12-26 16:11:07 |
Message-ID: | AANLkTikstq4meyptKjCeQE_Zm-peuGxJYmDqt-kuUPRk@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 12/25/10, Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com> wrote:
> Jeff Janes wrote:
>> If the background writer cannot keep up, then the individual backends
>> start doing writes as well, so it isn't really serialized..
>>
>>
> Is there any parameter governing that behavior?
No, it is automatic.
There are parameters governing how likely it is that bgwriter falls
behind in the first place, though.
http://www.postgresql.org/docs/9.0/static/runtime-config-resource.html
In particular bgwriter_lru_maxpages could be made bigger and/or
bgwriter_delay smaller.
But bulk copy binary might use a nondefault allocation strategy, and I
don't know enough about that part of the code to assess the
interaction of that with bgwriter.
> Can you tell me where in
> the code (version 9.0.2) can I find
that? Thanks.
Bufmgr.c, specifically BufferAlloc.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-12-26 17:24:47 | Re: encourging bitmap AND |
Previous Message | Marti Raudsepp | 2010-12-26 06:50:49 | Re: encourging bitmap AND |