Re: planner/optimizer question - Mailing list pgsql-performance

From Manfred Koizar
Subject Re: planner/optimizer question
Date
Msg-id ra9990hea0ats52frhjd6u0c5dsbr7jkmd@email.aon.at
Whole thread Raw
In response to Re: planner/optimizer question  (Jochem van Dieten <jochemd@oli.tudelft.nl>)
Responses Re: planner/optimizer question  ("Jochem van Dieten" <jochemd@oli.tudelft.nl>)
List pgsql-performance
On Sat, 01 May 2004 13:18:04 +0200, Jochem van Dieten
<jochemd@oli.tudelft.nl> wrote:
>Tom Lane wrote:
>> Oh really?  I think you need to think harder about the transition
>> conditions.

Indeed.

>>
>> Dead-to-all is reasonably safe to treat as a hint bit because *it does
>> not ever need to be undone*.  Visible-to-all does not have that
>> property.
>
>Yes, really :-)

No, not really :-(

As Tom has explained in a nearby message his concern is that -- unlike
dead-to-all -- visible-to-all starts as false, is set to true at some
point in time, and is eventually set to false again.  Problems arise if
one backend wants to set visible-to-all to true while at the same time
another backend wants to set it to false.

This could be curable by using a second bit as a deleted flag (might be
even the same bit that's now used as dead-to-all, but I'm not sure).  An
index tuple having both the visible flag (formerly called
visible-to-all) and the deleted flag set would cause a heap tuple access
to check visibility.  But that leaves the question of what to do after
the deleting transaction has rolled back.  I see no clean way from the
visible-and-deleted state to visible-to-all.

This obviously needs another round of hard thinking ...


pgsql-performance by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Wierd context-switching issue on Xeon
Next
From: James Thornton
Date:
Subject: Recommended File System Configuration