> The objections to synchronized scans for VACUUM as listed in that thread
> (summary):
> 2. vacuum takes breaks from the scan to clean up the indexes when it
> runs out of maintenance_work_mem.
> 2. There have been suggestions about a more compact representation for
> the tuple id list. If this works, it will solve this problem.
It will certainly not "solve" the problem. What it will do is mean that
the breaks are further apart and longer, which seems to me to make the
conflict with syncscan behavior worse not better.
> 3. vacuum takes breaks for the cost delay
> 3. Offering synchronized vacuums could reduce the need for these
> elective pauses.
How so? A vacuum that happens not to be part of a syncscan herd is
going to be just as bad for system performance as ever.
It still seems to me that vacuum is unlikely to be a productive member
of a syncscan herd --- it just isn't going to have similar scan-speed
behavior to typical queries.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment