Re: pg_dump restore time and Foreign Keys
От | Filip Rembiałkowski |
---|---|
Тема | Re: pg_dump restore time and Foreign Keys |
Дата | |
Msg-id | 92869e660806090909n39f07080m64acc8e4f4321202@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_dump restore time and Foreign Keys (Simon Riggs <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
2008/6/9 Simon Riggs <simon@2ndquadrant.com>:
just a guess, but maybe "create FK concurrently" feature combined with "synchronized scan" feature _does_ resolve original problem.
if you run many "create FK concurrently" one after another, wouldn't the seq scan be reused?
That's good, but it doesn't solve the original user complaint about
On Mon, 2008-06-09 at 10:57 -0400, Tom Lane wrote:
> Decibel! <decibel@decibel.org> writes:
> > Actually, in the interest of stating the problem and not the
> > solution, what we need is a way to add FKs that doesn't lock
> > everything up to perform the key checks.
>
> Ah, finally a useful comment. I think it might be possible to do an
> "add FK concurrently" type of command that would take exclusive lock
> for just long enough to add the triggers, then scan the tables with just
> AccessShareLock to see if the existing rows meet the constraint, and
> if so finally mark the constraint "valid". Meanwhile the constraint
> would be enforced against newly-added rows by the triggers, so nothing
> gets missed. You'd still get a small hiccup in system performance
> from the transient exclusive lock, but nothing like as bad as it is
> now. Would that solve your problem?
needing to re-run many, many large queries to which we already know the
answer.
just a guess, but maybe "create FK concurrently" feature combined with "synchronized scan" feature _does_ resolve original problem.
if you run many "create FK concurrently" one after another, wouldn't the seq scan be reused?
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Filip Rembiałkowski
В списке pgsql-hackers по дате отправления: