Re: Buglist - Mailing list pgsql-general

I don't think the problem will be deleting the tuple itself, if I've been following this correclty. If every
transactionleft it's signature in some common, global array, where each transaction finishing its work could find out
'who'sout there', killing unnneed transactions could be part of the exit routine. 

But getting the indexes cleaned up, that's another story, from what I've been listening to.

Bruno Wolff III wrote:

> 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.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org
>