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. ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
