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

One more thing came to my mind:
WAL records done by the GiST before patch will corrupt GiST after
patch if replayed.
Is it a problem? May be it's prevented on some higher level?

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

2016-07-06 22:11 GMT+05:00 Andrew Borodin <borodin(at)octonica(dot)com>:
> Here is a new patch. Updates:
> 1. Uses MAXALIGN to allocate space on page
> 2. Uses ItemIdSetNormal in case when ItemId was not normal for some
> reasons before call
> 3. Improved comments and var names
>
> Best regards, Andrey Borodin, Octonica & Ural Federal University.
>
> 2016-07-05 17:54 GMT+05:00 Andrew Borodin <borodin(at)octonica(dot)com>:
>> 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