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 <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +