>>>>> "BW" == Bruno Wolff, <Bruno> writes:
BW> It would probably be a lot slower. Any transaction that has started
BW> but not yet finished would need to lock all rows that exist at during
BW> the transaction (for serialized transaction isolation you would only
Why would you need to lock rows? Does the current vacuum need it? I
don't think it does. Why can't the functionality of vacuum be made to
operate incrementally per row delete/update? I don't know if it is
possible.
BW> Also, since at least 7.3, normal vacuums aren't normally going to
BW> affect the performance of your database server that much.
I disagree. Triggering a vacuum on a db that is nearly saturating the
disk bandwidth has a significant impact.
BW> The main issue against the current vacuum system is that it requires the
BW> DBA knowing what vacuum does and figuring out how it should be used in
BW> their situation to get reasonable performance. This makes it a bit harder
BW> for non-DBAs to jump right in to Postgres without running into problems.
BW> However, the work on autovacuum seems to be providing a reasonable solution
BW> to that problem.
Yes, this is a good thing.