Re: planner/optimizer question
От | Manfred Koizar |
---|---|
Тема | Re: planner/optimizer question |
Дата | |
Msg-id | ra9990hea0ats52frhjd6u0c5dsbr7jkmd@email.aon.at обсуждение исходный текст |
Ответ на | Re: planner/optimizer question (Jochem van Dieten <jochemd@oli.tudelft.nl>) |
Ответы |
Re: planner/optimizer question
|
Список | 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 по дате отправления: