Jim Nasby <
Jim.Nasby@BlueTreble.com> wrote:
On 3/27/15 5:15 AM, Vladimir Borodin wrote:
Master writes this record to xlog in btvacuumscan function after
vacuuming of all index pages. And in case of no pages with
deleted items xlog record would contain lastBlockVacuumed 0.
In btree_xlog_vacuum replica reads all blocks from
lastBlockVacuumed to last block of the index while applying this
record because there is no api in the buffer manager to
understand if the page is unpinned.
So if the index is quite big (200+ GB in described case) it
takes much time to do it.
2. Is it possible not to write to xlog record with
lastBlockVacuumed 0 in some cases? For example, in case of not
deleting any pages.
Possibly, but that's much higher risk. Without studying it, if we
wanted to mess around with that it might actually make more sense
to XLOG a set of blkno's that got vacuumed, but I suspect that
wouldn't be a win.
I feel pretty confident that it would be a win in some significant
cases, but it could be worse in some cases by changing sequential
access to random, unless we use heuristics to protect against
that. But...
Or maybe there are some better ways of improving this situation?
This is a start of a better way:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2ed5b87f96d473962ec5230fd820abfeaccb2069If we expand on that commit to cover non-MVCC index scans,
index-only scans, and index scans of non-WAL-logged indexes, then
this whole aspect of btree vacuum can be eliminated. It seems
extremely dubious that all of that could be done for 9.5, and it's
certainly not material for back-patching to any stable branches,
but it would be a more complete and better-performing fix than the
alternatives being discussed here.