"Tom Lane" <[EMAIL PROTECTED]> writes: > Alvaro Herrera <[EMAIL PROTECTED]> writes: >> 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". > > It would only be useful to have one per spindle-dedicated-to-WAL, so > tying the division to databases doesn't seem like it'd be a good idea.
I think one-per-database would help if you had a very particular type of application which had a lot of equally busy databases. In general to eliminate the bottleneck I think you would need to be able to break them up by process. So two processes writing to the same table would be able to write to different WAL logs. That sounds hard but I'm not sure. It may not be as bad as it sounds. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
