Re: Synchronized scans

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Synchronized scans
Date: 2007-06-10 19:45:32
Message-ID: 1181504732.27931.112.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

On Sat, 2007-06-09 at 09:58 -0400, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> > * For a large table, do lazy_scan_heap, scan_heap, and a sequential
> > scan usually progress at approximately the same rate?
>
> scan_heap would probably be faster than a regular seqscan, since it
> isn't doing any where-clause-checking or data output. Except if you've
> got vacuum-cost-limit enabled, which I think is likely to be true by
> default in future. Another problem is that lazy_scan_heap stops every
> so often to make a pass over the table's indexes, which'd certainly
> cause it to fall out of sync with more typical seqscans.

I think that these problems are significant enough that I'm not sure
sync-scanning a VACUUM is the right way to approach the problem.

Maybe a better solution would be to try to get a sequential scan to do
some of the work required by a VACUUM. I don't think we can stop in the
middle of a sequential scan to vacuum the indexes, but perhaps we could
come up with some kind of scheme. It would be cheaper (perhaps) to spill
the list of deletable TIDs to disk than to rescan a big (mostly live)
table later. And if it was costly, we wouldn't need to do the scan part
of a VACUUM on every sequential scan.

I'm sure this has been brought up before, does someone have a pointer to
a discussion about doing VACUUM-like work in a sequential scan?

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Heikki Linnakangas 2007-06-10 19:49:24 Re: Controlling Load Distributed Checkpoints
Previous Message Magnus Hagander 2007-06-09 20:55:55 Re: Regression tests