Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > Tom Lane wrote:
> >> You don't. As I said, any physical backup is going to be
> >> all-or-nothing. These techniques are not a replacement for pg_dump.
>
> > But this is just an artifact of the fact that the WAL is a single
> > instance-wide entity, rather than a per-database entity. But since
> > databases are completely separate entities that cannot be simultaneously
> > accessed by any query (corrections welcome), there isn't any reason in
> > principle that the WAL files cannot also be created on a per-database
> > basis.
>
> 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.
>
> If you want to do separate physical dumps/restores, the answer is to set
> up separate clusters (separate postmasters). Not so hard, is it?
Well, aside from the fact that separate clusters have completely separate
user databases, listen on different ports, will compete with other
clusters on the same system for resources that would be better managed
by a single cluster, and generally have to be maintained as completely
separate entities from start to finish, no it's not that hard. ;-)
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.
It's probably something that we'll have to deal with if we want PG to be
useful to people managing really large databases on really, really big
iron, though.
--
Kevin Brown kevin@sysexperts.com
