Kevin Brown wrote:
>>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