Skip site navigation (1) Skip section navigation (2)

synchronized scans for VACUUM

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: synchronized scans for VACUUM
Date: 2008-06-01 01:10:06
Message-ID: 1212282606.6360.43.camel@jdavis (view raw or flat)
Thread:
Lists: pgsql-hackers
Previous thread for reference:

http://archives.postgresql.org/pgsql-patches/2007-06/msg00096.php

The objections to synchronized scans for VACUUM as listed in that thread
(summary):

1. vacuum sometimes progresses faster than a regular heapscan, because
it doesn't need to check WHERE clauses, etc.

2. vacuum takes breaks from the scan to clean up the indexes when it
runs out of maintenance_work_mem.

3. vacuum takes breaks for the cost delay

4. vacuum will dirty a lot of the blocks as it goes, and that will cause
some kind of interaction with the ring buffer

I'd like to address these one by one to see what problems are really in
our way:

1. This would mean that it's not an I/O limited scan. I think as long as
we're talking about regular table scans that can benefit from
synchronized scanning, a vacuum of the same table would also benefit. A
microbenchmark could show whether some benefit exists or not.

2. There have been suggestions about a more compact representation for
the tuple id list. If this works, it will solve this problem.

3. Offering synchronized vacuums could reduce the need for these
elective pauses. 

4. This probably has more to do with the buffer ring than synchronized
scans. There could be some bad interaction there, but I don't see that
it's clearly bad.

Additionally, with the possible exception of #4, I don't see the
situation being worse than it is currently.

Thoughts?

Regards,
	Jeff Davis


Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-06-01 01:41:55
Subject: Re: Overhauling GUCS
Previous:From: Sushant SinhaDate: 2008-05-31 23:58:41
Subject: Re: [GENERAL] Fragments in tsearch2 headline

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group