Re: [v9.2] make_greater_string() does not return a string in some cases - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [v9.2] make_greater_string() does not return a string in some cases
Date
Msg-id 18585.1316702645@sss.pgh.pa.us
Whole thread Raw
In response to Re: [v9.2] make_greater_string() does not return a string in some cases  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> On Thu, Sep 22, 2011 at 2:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The essential problem here is "when can you stop scanning,
>> given a pattern with this prefix?", and btree doesn't know any more
>> about that than make_greater_string does; it would in fact have to use
>> make_greater_string or something isomorphic to it.

> Hm, as long as btree_pattern_ops is the only opclass that behaves this
> way that's more or less true. But Robert's right that if btree just
> stops when it finds something that doesn't match it doesn't need to
> hard code any knowledge of what the "next" value would be.

But you've added mechanism (and hence cycles) to btree searches,
and *you haven't actually gained anything*.  If the feature is
restricted to only work for sort orderings in which common-prefix
strings are contiguous, then it doesn't do anything we can't do
just as well with the existing mechanism.  Moreover, you'll still
need make_greater_string because of the problem of trying to extract
LIKE selectivity estimates from locale-dependent pg_statistic data.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [v9.2] make_greater_string() does not return a string in some cases
Next
From: Peter Geoghegan
Date:
Subject: Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs)