WAL is not the bottleneck ... as I already mentioned today, pg_clog (and more specifically the meaning of transaction IDs) is what really makes a cluster an indivisible whole at the physical level.
The ability to restore a single large database quickly is, I think, a reasonable request, it's just that right now it's difficult (perhaps impossible) to satisfy that request.
I could live perfectly with a single database restore solution that can't cope with WAL, but merely contains the very snapshot present at the CHECKPOINT when the backup started.
Additionally, I could imagine a restore where only one db is restored, and the WAL is replayed from the complete cluster backup set, while ignoring all WAL entries not meant for the database in restauration.
Imagine you have a full backup at midnight, and at at 5PM you say "sh*t, I need to have an 11am PITR on my ABC database, while leaving the other five in the cluster untouched". I'd drop that offending DB, restore it, and replay that WAL.
Does this sound too esoteric?
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
