Re: B-Tree support function number 3 (strxfrm() optimization) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id CAM3SWZQNO2k2yn3gvD+F0iwgqX-7TRNwfYvPjG6nAj5pZMQZuA@mail.gmail.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)
Re: B-Tree support function number 3 (strxfrm() optimization)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: parallel mode and parallel contexts
Next
From: Amit Langote
Date:
Subject: Re: Parallel Seq Scan