Re: RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
От | Peter Geoghegan |
---|---|
Тема | Re: RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() |
Дата | |
Msg-id | CAH2-WzkE0-ab6u2ZnDct+BxCE8h=Qze31U0vgEOziG-yf83cBA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare() (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>) |
Ответы |
Re: RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
|
Список | 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 по дате отправления: