| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Greg Stark <stark(at)mit(dot)edu>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [v9.2] make_greater_string() does not return a string in some cases |
| Date: | 2011-09-22 13:51:12 |
| Message-ID: | 17571.1316699472@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Sep 22, 2011 at 8:59 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
>> But the whole problem is that not all the strings with the initial
>> substring are in a contiguous block.
> If that were true for the sorts of indexes we're using for LIKE
> queries, the existing approach wouldn't work either.
Right. Since it's not a problem for the sorts of indexes with which we
can use LIKE, moving knowledge of LIKE into the btree machinery doesn't
buy us a darn thing, except more complexity in a place where we can ill
afford it. 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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2011-09-22 14:28:53 | Re: [v9.2] make_greater_string() does not return a string in some cases |
| Previous Message | Robert Haas | 2011-09-22 13:27:21 | Re: [v9.2] make_greater_string() does not return a string in some cases |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-09-22 13:55:35 | Re: memory barriers (was: Yes, WaitLatch is vulnerable to weak-memory-ordering bugs) |
| Previous Message | Robert Haas | 2011-09-22 13:27:21 | Re: [v9.2] make_greater_string() does not return a string in some cases |