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

From Robert Haas
Subject Re: B-Tree support function number 3 (strxfrm() optimization)
Date
Msg-id CA+TgmoZ7ZQo8uGZbxO-cNH_bQGEhkzcCerYmv39Bmk_LO9XRsA@mail.gmail.com
Whole thread Raw
In response to Re: B-Tree support function number 3 (strxfrm() optimization)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: B-Tree support function number 3 (strxfrm() optimization)
List pgsql-hackers
On Tue, Dec 2, 2014 at 5:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Geoghegan <pg@heroku.com> writes:
>> On Tue, Dec 2, 2014 at 2:21 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Right, and what I'm saying is that maybe the "applicability" flag
>>> shouldn't be stored in the SortSupport object, but passed down as an
>>> argument.
>
>> But then how does that information get to any given sortsupport
>> routine? That's the place that really needs to know if abbreviation is
>> useful. In general, they're only passed a SortSupport object. Are you
>> suggesting revising the signature required of SortSupport routines to
>> add that extra flag as an additional argument?
>
> I think that is what he's suggesting, and I too am wondering why it's
> a good idea.

I find it somewhat confusing that we've got one flag which is only
used from the time the SortSupport object is created until the time
that it's fully initialized, and then a different way of indicating
whether we paid attention to that flag.  I'm not totally sure what the
right solution to that problem is, but the current situation feels
like something of a wart.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: "ktm@rice.edu"
Date:
Subject: Re: On partitioning
Next
From: José Luis Tallón
Date:
Subject: Re: Sequence Access Method WIP