From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | David Schnur <dnschnur(at)gmail(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: REINDEX disk space requirements |
Date: | 2009-11-06 18:18:40 |
Message-ID: | 20091106181840.GH3840@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
David Schnur escribió:
> On Fri, Nov 6, 2009 at 12:11 PM, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
> wrote:
>
> > Immediately after the deletions, or is there some delay? Keep in mind
> > that rows cannot be reclaimed until the oldest transaction that was open
> > when they were deleted is finished.
>
> The VACUUM waits until after the DELETE has been committed. But when you
> refer to the oldest transaction, do you mean any transaction at all?
Yes. But it goes back even further: is there any other transaction
running that was also running when the DELETE started? If there is,
vacuum won't be able to reclaim the rows.
> Currently it's guaranteed that no other transaction is running when VACUUM
> starts, but we were thinking of changing that behavior. It would then be
> possible for an INSERT in a separate transaction to start running ~10
> seconds before the DELETE is done, and continue running for ~10 seconds
> after the VACUUM starts.
>
> Is that the problem you were referring to?
Yes. You'd have to wait until the INSERT is finished, and run VACUUM
then.
> How does VACUUM behave in that situation? It sounds like it returns
> without reclaiming anything?
Yes.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2009-11-06 20:39:56 | Re: Windows postgresql back using linux |
Previous Message | ABBAS SHAKEEL | 2009-11-06 17:51:57 | Windows postgresql back using linux |