Heikki Linnakangas wrote: > Tom Lane wrote: > > I wrote: > >> Hmm ... also check commit status (pg_clog access). I've always thought > >> that those things couldn't be done in bgwriter, because it wasn't > >> running real transactions, but right at the moment I can't see that > >> there is any obstacle. Perhaps that meme dates from a time when > >> GetOldestXmin didn't work outside a transaction? > > > > On further thought, I think what I'm remembering is that full-scale > > VACUUM can't work inside bgwriter, because you need to take table-level > > locks and worry about index vs heap consistency. But as long as HOT > > pruning involves only a single heap page I see no need for it to take > > more than the buffer-level locks on that page. > > One complication is that you need to identify heap pages; you don't want > to start pruning index pages. We could mark the buffer with a new > Prunable-flag when an it's updated, to signal the bgwriter that it can > prune it. > > I wonder if pruning in bgwriter only is enough to make HOT work > efficiently. On a very frequently updated page, bgwriter will have to > work hard to keep up. > > Another problematic scenario is a big table and small shared_buffers > (like on Windows). Page can easily fall out of the buffer cache, before > bgwriter has the chance to prune anything on it. > > But if it works reasonably well in typical scenarios, we can go with > that for 8.3 and improve later.
I don't like pushing pruning to the bgwriter. I am afraid we get into the same problem with autovacuum where polling via the bgwriter will frequently not happen just-in-time, when we need it. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
