On 8 August 2014 16:03, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> I couldn't resist starting to hack on this, and implemented the scheme I've
> been having in mind:
>
> 1. MMTuple contains the block number of the heap page (range) that the tuple
> represents. Vacuum is no longer needed to clean up old tuples; when an index
> tuples is updated, the old tuple is deleted atomically with the insertion of
> a new tuple and updating the revmap, so no garbage is left behind.
>
> 2. LockTuple is gone. When following the pointer from revmap to MMTuple, the
> block number is used to check that you land on the right tuple. If not, the
> search is started over, looking at the revmap again.
Part 2 sounds interesting, especially because of the reduction in CPU
that it might allow.
Part 1 doesn't sound good yet.
Are they connected?
More importantly, can't we tweak this after commit? Delaying commit
just means less time for other people to see, test, understand tune
and fix. I see you (Heikki) doing lots of incremental development,
lots of small commits. Can't we do this one the same?
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
