Re: Avoiding second heap scan in VACUUM

From: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Postgres - Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoiding second heap scan in VACUUM
Date: 2008-05-30 11:19:03
Message-ID: 2e78013d0805300419yc5d6e60h2535697df250f83d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, May 30, 2008 at 3:31 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
>
> Perhaps we can start first scan, check xid after we scan each few
> blocks. Once we find the xid is older, then we know the size of the
> second scan can be limited to only those blocks already scanned. So the
> two endpoints of behaviour are we skip the scan completely or we do the
> whole scan, but at least there is a saving in many cases without
> waiting.
>

Hmm. Interesting. I was about to suggest that we use some heuristic
such as size of the table to decide whether or not try the
optimization. But what you just suggested makes more sense. So instead
of waiting, we anyways start the first scan. If we are lucky, in some
time all the old transactions would go away and then we can start
marking the DEAD line pointers as DEAD_RECLAIMED. The second pass just
needs to rescan the initial blocks to remove the DEAD line pointers.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Radek Strnad 2008-05-30 13:06:38 Re: Proposal - Collation at database level
Previous Message Dirk Riehle 2008-05-30 10:21:53 Feedback on blog post about Replication Feature decision and its impact