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

Поиск
Список
Период
Сортировка
От Andrew Borodin
Тема Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]
Дата
Msg-id CAJEAwVGZ874L5FrScnVWeq8Banpgg=8rDFL30nEOVUw7SxJXJA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]  (Andrew Borodin <borodin@octonica.com>)
Ответы Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]
Список 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@octonica.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@octonica.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@2ndquadrant.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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "petrum@gmail.com"
Дата:
Сообщение: Question about an inconsistency - 1
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: primary_conninfo missing from pg_stat_wal_receiver