From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | Jochem van Dieten <jochemd(at)oli(dot)tudelft(dot)nl> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: planner/optimizer question |
Date: | 2004-05-02 08:03:36 |
Message-ID: | ra9990hea0ats52frhjd6u0c5dsbr7jkmd@email.aon.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, 01 May 2004 13:18:04 +0200, Jochem van Dieten
<jochemd(at)oli(dot)tudelft(dot)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 ...
From | Date | Subject | |
---|---|---|---|
Next Message | James Thornton | 2004-05-02 08:11:12 | Recommended File System Configuration |
Previous Message | Dave Cramer | 2004-05-01 18:50:47 | Re: Wierd context-switching issue on Xeon |