Re: Minmax indexes

On 08/10/2014 12:42 PM, Simon Riggs wrote:
> On 8 August 2014 16:03, Heikki Linnakangas <hlinnakangas(at)vmware(dot)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?

Yes. The optimistic locking in part 2 is based on checking that the
block number on the MMTuple matches what you're searching for, and that
there is never more than one MMTuple in the index with the same block
number.

> 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?

Well, I wouldn't consider "let's redesign how locking and vacuuming
works and change the on-disk format" as incremental development ;-).
It's more like, well, redesigning the whole thing. Any testing and
tuning would certainly need to be redone after such big changes.

If you agree that these changes make sense, let's do them now and not
waste people's time testing and tuning a dead-end design. If you don't
agree, then let's discuss that.

- Heikki