On Wed, Aug 20, 2003 at 12:40:03 -0400,
Vivek Khera <khera@kcilink.com> wrote:
> >>>>> "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.
How do you plan on knowing when no one is using a row any more?
The way vacuum uses is not suitable for deleting the row after the
last transaction that can see the row completes. When rows are created
they are marked with the transaction id of the transaction that created
the row. When they are deleted they are marked with the transaction id
of the transaction that deleted the row. Any transaction with an id
between those two ids can see the row. So it isn't the transaction that
deletes a row that needs to worry about marking its space as available,
but the last transaction that a row is visible to that would have to
do it. Naively, this entails scanning the whole database, just like a vacuum
would, after each completed transaction.
> 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.
If you are running that close to the edge you have potential problems
of which running vacuum is just one.
