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

From: Andrew Borodin <borodin(at)octonica(dot)com>
To: Andrew Borodin <amborodin(at)acm(dot)org>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Sergey Mirvoda <sergey(at)mirvoda(dot)com>
Subject: Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]
Date: 2016-07-06 17:11:13
Message-ID: CAJEAwVGZ874L5FrScnVWeq8Banpgg=8rDFL30nEOVUw7SxJXJA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
PageIndexTupleOverwrite v4.patch application/octet-stream 6.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2016-07-06 17:38:13 Re: primary_conninfo missing from pg_stat_wal_receiver
Previous Message petrum@gmail.com 2016-07-06 16:07:14 Question about an inconsistency - 1