On Thu, 2008-05-29 at 09:57 +0530, Pavan Deolasee wrote: > On Thu, May 29, 2008 at 2:02 AM, Simon Riggs <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
