Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow
От | Peter Geoghegan |
---|---|
Тема | Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow |
Дата | |
Msg-id | CAH2-Wz=ad_ZLvzjJ0sXUS0cBgAe7xWsMh-CpDzL9t7gq1gQ=-A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14722: Segfault in tuplesort_heap_siftup, 32 bit overflow (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-bugs |
On Wed, Jul 5, 2017 at 3:19 PM, Peter Geoghegan <pg@bowt.ie> wrote: > I doubt that myself. Especially prior to Postgres 10, where merging > will have tuplesort_heap_insert() as the bottleneck. BTW, I do of course understand that the reporter isn't talking about merging, but rather is talking about run generation using replacement selection. Replacement selection is more or less obsolete, and was more or less removed in Postgres 9.6. I don't think that its needs should be given much weight here; this is mostly about merging. I wanted to make merging use its own dedicated function within the patch that became 24598337c8d, and leave tuplesort_heap_insert() and tuplesort_heap_siftup() as things used only by replacement selection + Top-N heap sort, but Heikki overruled me on that. He might have been right about that. I'm not sure, and never took the time to follow up with it. tuplesort_heap_replace_top(), which is where this logic lives now that tuplesort_heap_siftup() was broken up, certainly is a red-hot code path where individual instructions could matter. I've looked at the disassembly of the function in the past, which is rare for me. -- Peter Geoghegan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: