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

Reply via email to