Re: pg_restore and create FK without verification check
От | Kevin Brown |
---|---|
Тема | Re: pg_restore and create FK without verification check |
Дата | |
Msg-id | 20031127032925.GN6073@filer обсуждение исходный текст |
Ответ на | Re: pg_restore and create FK without verification check (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_restore and create FK without verification check
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: