Re: B-Tree support function number 3 (strxfrm() optimization)

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: B-Tree support function number 3 (strxfrm() optimization)
Дата
Msg-id CAM3SWZQNO2k2yn3gvD+F0iwgqX-7TRNwfYvPjG6nAj5pZMQZuA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: B-Tree support function number 3 (strxfrm() optimization)  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Re: B-Tree support function number 3 (strxfrm() optimization)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Jan 20, 2015 at 6:39 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Tue, Jan 20, 2015 at 6:34 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> That might be OK.  Probably needs a bit of performance testing to see
>> how it looks.
>
> Well, we're still only doing it when we do our final merge. So that's
> "only" doubling the number of conversions required, which if we're
> blocked on I/O might not matter at all.

You'll probably prefer the attached. This patch works by disabling
abbreviation, but only after writing out runs, with the final merge
left to go. That way, it doesn't matter when abbreviated keys are not
read back from disk (or regenerated).

I believe this bug was missed because it only occurs when there are
multiple runs, and not in the common case where there is one big
initial run that is found already sorted when we reach mergeruns().
--
Peter Geoghegan

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: parallel mode and parallel contexts
Следующее
От: Amit Langote
Дата:
Сообщение: Re: Parallel Seq Scan