On Sat, 2007-06-09 at 09:58 -0400, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.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
