From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> |
Cc: | Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Avoiding second heap scan in VACUUM |
Date: | 2008-05-29 05:45:37 |
Message-ID: | 1212039937.4489.727.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2008-05-29 at 09:57 +0530, Pavan Deolasee wrote:
> On Thu, May 29, 2008 at 2:02 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >
> >
> > I'm not happy that the VACUUM waits. It might wait a very long time and
> > cause worse overall performance than the impact of the second scan.
> >
>
> Lets not get too paranoid about the wait. It's a minor detail in the
> whole theory. I would suggest that the benefit of avoiding second scan
> would be huge. Remember, its just not a scan, it also dirties those
> blocks again, forcing them write to disk. Also, if you really have a
> situation where vacuum needs to wait for very long, then you are
> already in trouble. The long running transactions would prevent
> vacuuming many tuples.
>
> I think we can easily tweak the "wait" so that it doesn't wait
> indefinitely. If the "wait" times out, vacuum can still proceed, but
> it can mark the DEAD line pointers as DEAD_RECLAIMED. It would then
> have a choice of making a second pass and reclaiming the DEAD line
> pointers (like it does today).
Which is exactly what I suggested. Don't wait, just check.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2008-05-29 06:44:34 | Re: BUG #4204: COPY to table with FK has memory leak |
Previous Message | Simon Riggs | 2008-05-29 05:41:44 | Re: BUG #4204: COPY to table with FK has memory leak |