22.08.2015 02:34, Ann Harrison wrote:

>
> Interesting. When we used the "one index entry per value" rules,
> maintenance was reasonably cheap, but the algoithm was fragile and
> subject to more problems as processors got faster. I suspect that
> there's a solution to that problem short of adding 128 bits to every
> index entry.

I hope so.

> I suspect that Postgres went the other
> way. They store their record versions oldest to newest (rather than
> vice versa) and (IIRC) their indexes point to the version, not the
> primary record.

Correct. This adds the index maintenance overhead for updates/deletes,
but allows faster GC without storage overhead for TIDs. Do you think
this approach is worth adopting?

This does not solve the index coverage, however. As a workaround, PGSQL
now uses the visibility bitmap to avoid fetching a data page if all its
rows are guaranteed to be visible to everyone. Kinda compromise solution
that surely works fine for the "old" data but unlikely to give any
advantage for the hot data pages in the oltp load.


Dmitry