Re: RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Date
Msg-id CAH2-WzkE0-ab6u2ZnDct+BxCE8h=Qze31U0vgEOziG-yf83cBA@mail.gmail.com
Whole thread Raw
In response to Re: RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Responses Re: RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
List pgsql-hackers
On Mon, Nov 2, 2020 at 9:46 AM Anastasia Lubennikova
<a.lubennikova@postgrespro.ru> wrote:
> This thread was inactive for a while. The latest review suggests that it is Ready For Committer.
> I also took a quick look at the patch and agree that it looks sensible. Maybe add a comment before the
_bt_compare_inl()to explain the need for this code change.
 

Actually I am probably going to withdraw this patch soon. The idea is
a plausible way of improving things. But at the same time I cannot
really demonstrate any benefit on hardware that I have access to.

This patch was something I worked on based on a private complaint from
Andres (who is CC'd here now) during an informal conversation at pgDay
SF. If Andres is now in a position to test the patch and can show a
benefit on certain hardware, I may well pick it back up. But as things
stand the evidence in support of the patch is pretty weak. I'm not
going to commit a patch like this unless and until it's crystal clear
what the benefits are.

if Andres cannot spend any time on this in the foreseeable future then
I'll withdraw the patch. I intend to formally withdraw the patch on
November 9th, provided no new information comes to light.

Thanks
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Reduce the number of special cases to build contrib modules on windows
Next
From: Peter Geoghegan
Date:
Subject: Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()