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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com