From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Rob Wultsch <wultsch(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Spread checkpoint sync |
Date: | 2010-12-07 02:26:28 |
Message-ID: | 1291688119-sup-6606@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Excerpts from Greg Smith's message of dom dic 05 20:02:48 -0300 2010:
> When ends up happening if you push toward fully sync I/O is the design
> you see in some other databases, where you need multiple writer
> processes. Then requests for new pages can continue to allocate as
> needed, while keeping any one write from blocking things. That's one
> sort of a way to simulate asynchronous I/O, and you can substitute true
> async I/O instead in many of those implementations. We didn't have much
> luck with portability on async I/O when that was last experimented with,
> and having multiple background writer processes seems like overkill;
> that whole direction worries me.
Why would multiple bgwriter processes worry you?
Of course, it wouldn't work to have multiple processes trying to execute
a checkpoint simultaneously, but what if we separated the tasks so that
one process is in charge of checkpoints, and another oneZis in charge of
the LRU scan?
--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-12-07 02:32:48 | Re: We really ought to do something about O_DIRECT and data=journalled on ext4 |
Previous Message | Tom Lane | 2010-12-07 02:13:29 | Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ |