Greg Stark <gsst...@mit.edu> writes:
> I like all of:
> 1) move the truncating to a new transaction just like we currently do
> toast tables in a separate transaction from the main vacuum.
+1 if we are going to continue the behavior of allowing other
transactions to kick autovac off the exclusive lock. However, if we can
find a way to avoid the need of that, then breaking it into multiple
transactions would just be useless complication (and extra cycles).
In particular, I thought the direction Jan was headed was to release and
reacquire the lock between truncating off limited-size chunks of the
file. If we do that, we probably *don't* want or need to allow autovac
to be booted off the lock more quickly.
> 2) Don't bother trying to truncate if we've been called from
> autovacuum at all.
No, I think that's seriously going in the wrong direction. We are
trying to make autovacuum more useful and transparent, not find new
reasons why people have to use manual vacuuming.
> 3) Scanning backwards 8MB at a time scanning each 8MB forwards instead
> of just going back by block backwards.
Maybe. I'd want to see some experimental evidence justifying the choice
of chunk size; I'm pretty sure this will become counterproductive once
the chunk size is too large.
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
