Heikki Linnakangas escribió:
> Another issue is that reading WAL is inherently not very scalable. There's
> only one WAL for the whole cluster, and it needs to be read sequentially,
> so it can easily become a bottleneck on large systems.
I have wondered why do we do it this way. Is there a problem with
having one WAL per database, and another for general operations? This
last WAL would have changes to shared tables, as well as global stuff
like "create database" or "create tablespace".
Of course, it means a lot more files, and a PITR setup is a bit more
complex.
One obvious problem is that it is no longer true that you have a "no
seek" disk head. But is there much use of that, these days? People
have either a big RAID on which the WAL resides along all data; or, on
low-cost systems, the whole thing is in a single disk or a small RAID.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
