From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Marti Raudsepp <marti(at)juffo(dot)org> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Separating bgwriter and checkpointer |
Date: | 2011-09-20 16:20:10 |
Message-ID: | CA+TgmoZ45XYbZ76s_-2UkkU=RymXOS5_YfMH2ZGcgUpLbzrLbA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 20, 2011 at 11:01 AM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> On Fri, Sep 16, 2011 at 01:53, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> This patch splits bgwriter into 2 processes: checkpointer and
>> bgwriter, seeking to avoid contentious changes. Additional changes are
>> expected in this release to build upon these changes for both new
>> processes, though this patch stands on its own as both a performance
>> vehicle and in some ways a refcatoring to simplify the code.
>
> While you're already splitting up bgwriter, could there be any benefit
> to spawning a separate bgwriter process for each tablespace?
>
> If your database has one tablespace on a fast I/O system and another
> on a slow one, the slow tablespace would also bog down background
> writing for the fast tablespace. But I don't know whether that's
> really a problem or not.
I doubt it. Most of the time the writes are going to be absorbed by
the OS write cache anyway.
I think there's probably more performance to be squeezed out of the
background writer, but maybe not that exact thing, and in any case it
seems like material for a separate patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-09-20 16:23:19 | Re: unite recovery.conf and postgresql.conf |
Previous Message | Tom Lane | 2011-09-20 15:42:21 | Re: File not found error on creating collation |