Re: Further open item (Was: Status of 7.2)
От | Tom Lane |
---|---|
Тема | Re: Further open item (Was: Status of 7.2) |
Дата | |
Msg-id | 21788.1006192468@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Further open item (Was: Status of 7.2) (Hannu Krosing <hannu@tm.ee>) |
Список | pgsql-hackers |
Hannu Krosing <hannu@tm.ee> writes: > I'd propose a memory-only (or heavily cached) structure of tuple death > transaction > ids for all transactions since the oldest live trx. Seems like just a special-purpose reimplementation of disk pages sitting in shared buffers. If you've got the memory to keep track of tuples you've killed recently, then you've probably got the memory to hold the pages they're in, so a redundant separate caching structure is not obviously a win. The possible win of marking index entries dead (once their tuple is known dead for all transactions) is that it saves visiting disk pages that have *not* been visited recently, and thus that aren't likely to be hanging around in buffers. OTOH there are a lot of potential problems, most notably that is-the-tuple-dead-for-ALL-transactions is not the normal tuple time qual check, and so it'd represent extra overhead in indexscans. I'm also concerned about how to do it without introducing lots of ugly interactions (maybe even deadlocks) between the index access methods and the heap access code. If concurrent vacuuming turns out to be cheap enough, just running vacuum frequently might be a better answer than trying to push the maintenance work into the main line of execution. regards, tom lane
В списке pgsql-hackers по дате отправления: