Tom Lane wrote:
> Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:
>
>>I was thinking about it. How about vacuuming a page when it is been
>>pushed out of postgresql buffer cache? It is is memory so not much IO
>>is involved.
>
>
> You keep ignoring the problem of removing index entries. To vacuum an
> individual page, you need to be willing to read in (and update) all
> index pages that reference the tuples-to-be-deleted. This is hardly
> tenable when the reason for pushing the page out of buffer cache was so
> that you could read in something else instead --- you don't have spare
> buffer slots, and you don't want to do all that I/O (and the associated
> WAL log entries) before you can read in the page you originally wanted.
>
> The latter point is really the crux of the problem. The point of having
> the VACUUM process is to keep maintenance work out of the critical path
> of foreground queries. Anything that moves even part of that
> maintenance work into the critical path is going to be a net loss.
So the problem is an index tuple does not store transaction id information like
a heap tuple does and it can not deduce that an index tuple is dead unless it
points to a dead heap tuple.
Is that right?
If an index tuple had transaction information duplicated along with heap tuple,
two types of tuples can be removed, independent of each other? Would above
scheme of vacuum-on-page-expiry work in that case?
Shridhar