Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC] - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]
Date
Msg-id CAA4eK1+wS4Oz99wz+4KV0S5fbM7ACWqA+mzsEr1ugn8brbRLtg@mail.gmail.com
Whole thread Raw
In response to Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]  (Andrew Borodin <borodin@octonica.com>)
Responses Re: Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]  (Andrew Borodin <borodin@octonica.com>)
List pgsql-hackers
On Mon, Jul 4, 2016 at 4:52 PM, Andrew Borodin <borodin@octonica.com> wrote:
> Here is a patch with corrections from Alexander Korotkov.
> My tests, check and check-world show no problems against Ubuntu LTS 14 x64 VM.
>
>

- PageIndexTupleDelete(page, oldoffnum);
- gistfillbuffer(page, itup, ntup, InvalidOffsetNumber);
+ {
+ /*if we have just one tuple to update we replace it on-place on page*/
+ if(ntup == 1)
+ {
+ PageIndexTupleOverwrite(page,oldoffnum,*itup);
+ }
+ else
+ {
+ /*this corner case is here to support mix calls case (see comment above)*/
+ PageIndexTupleDelete(page, oldoffnum);
+ gistfillbuffer(page, itup, ntup, InvalidOffsetNumber);
+ }


Here, you have changed the way tuple is added on a page, but still the
WAL record is same as before.  I think WAL replay should perform the
action in a same way as we have done when original operation is
performed.  If not, then it can change the organization of page which
might lead to failure in replay of consecutive WAL records.

+ /*if we have just one tuple to update we replace it on-place on page*/

In comments, we always leave a space both in the beginning and at the
end of a comment.  See comments in nearby code.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Vladimir Borodin
Date:
Subject: Re: [PERFORM] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
Next
From: Amit Kapila
Date:
Subject: Re: to_date_valid()