Re: planner/optimizer question
От | Jochem van Dieten |
---|---|
Тема | Re: planner/optimizer question |
Дата | |
Msg-id | 4093876C.2060409@oli.tudelft.nl обсуждение исходный текст |
Ответ на | Re: planner/optimizer question (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: planner/optimizer question
Re: planner/optimizer question Re: planner/optimizer question |
Список | pgsql-performance |
Tom Lane wrote: > Manfred Koizar <mkoi-pg@aon.at> writes: >> >> Yes, the visible-to-all flag would be set as a by-product of an index >> scan, if the heap tuple is found to be visible to all active >> transactions. This update is non-critical > > Oh really? I think you need to think harder about the transition > conditions. > > 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 :-) When a tuple is inserted the visible-to-all flag is set to false. The effect of this is that every index scan that finds this tuple has to visit the heap to verify visibility. If it turns out the tuple is not only visible to the current transaction, but to all current transactions, the visible-to-all flag can be set to true. This is non-critical, because if it is set to false scans will not miss the tuple, they will just visit the heap to verify visibility. The moment the heap tuple is updated/deleted the visible-to-all flag needs to be set to false again in all indexes. This is critical, and the I/O and (dead)lock costs of unsetting the visible-to-all flag are unknown and might be big enough to ofset any advantage on the selects. But I believe that for applications with a "load, select, drop" usage pattern (warehouses, archives etc.) having this visible-to-all flag would be a clear winner. Jochem -- I don't get it immigrants don't work and steal our jobs - Loesje
В списке pgsql-performance по дате отправления: