Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

Here is a patch with updated WAL behavior.

I'm not certain about MAXALIGN for size of appended tuple. Currently
if anyone calls PageIndexTupleOverwrite() with unalligned tuple it
will ereport(ERROR).
I suspect that it should allign size instead.

Also I suspect that PageIndexTupleOverwrite() should make a call to
ItemIdSetNormal() to pretend it is generic function and not just a
private part of GiST.

Best regards, Andrey Borodin, Octonica & Ural Federal University.

2016-07-04 22:59 GMT+05:00 Andrew Borodin <borodin(at)octonica(dot)com>:
> Thank you, Alvaro.
>
> Yes, now I see. I'll update gistRedoPageUpdateRecord() to work
> accordingly with patched gistplacetopage().
> Also, i've noticed that PageAddItem uses MAXALIGN() macro to calculate
> tuple size. So, PageIndexTupleOverwrite should behave the same.
>
> About PageIndexDeleteNoCompact() in BRIN. I do not see why
> PageIndexDeleteNoCompact() is not a good solution instead of
> PageIndexTupleOverwrite? Will it mark tuple as unused until next
> PageAddItem will use it's place?
>
> Best regards, Andrey Borodin, Octonica & Ural Federal University.
>
> 2016-07-04 22:16 GMT+05:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
>> Andrew Borodin wrote:
>>> Thank you, Amit.
>>>
>>> Currently, if WAL reconstruct page in another order it won't be a problem.
>>
>> We require that replay of WAL leads to identical bytes than the
>> original. Among other things, this enables use of a tool that verifies
>> that WAL is working correctly simply by comparing page images. So
>> please fix it instead of just verifying that this works for GiST.
>>
>> By the way, BRIN indexes have a need of this operation too. The current
>> approach is to call PageIndexDeleteNoCompact followed by PageAddItem.
>> I suppose it would be beneficial to use your new routine there too.
>>
>> --
>> Álvaro Herrera http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services