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 | CAJEAwVGBN6BK4UHUvFqc-HZAMqOD0UV4bXh0Y4A5DtYnjSJnGQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC] (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Re: GiST optimizing memmoves in gistplacetopage for
fixed-size updates [PoC]
|
Список | pgsql-hackers |
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 по дате отправления: