Re: Set visibility map bit after HOT prune
От | Tom Lane |
---|---|
Тема | Re: Set visibility map bit after HOT prune |
Дата | |
Msg-id | 29275.1355608088@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Set visibility map bit after HOT prune (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Set visibility map bit after HOT prune
Re: Set visibility map bit after HOT prune Re: Set visibility map bit after HOT prune |
Список | pgsql-hackers |
Simon Riggs <simon@2ndQuadrant.com> writes: > Doing that only makes sense when we're running a SELECT. Setting the > all visible bit immediately prior to an UPDATE that clears it again is > pointless effort, generating extra work for no reason. On the other hand, the HOT prune operation itself is worthless when we're running a SELECT. The only reason we do it that way is that we have to prune before the query starts to use the page, else pruning might invalidate pointers-to-tuples that are being held within the query plan tree. Maybe it's time to look at what it'd take for the low-level scan operations to know whether they're scanning the target relation of an UPDATE query, so that we could skip pruning altogether except when a HOT update could conceivably ensue. I think this was discussed back when HOT went in, but nobody wanted to make the patch more invasive than it had to be. regards, tom lane
В списке pgsql-hackers по дате отправления: