| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>, "pgsql-performance" <pgsql-performance(at)postgresql(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Estimation problem with a LIKE clause containing a / |
| Date: | 2007-11-08 23:10:49 |
| Message-ID: | 87prykpc3q.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> What I am tempted to do about this is have make_greater_string tack "zz"
> onto the supplied prefix, so that it would have to find a string that
> compares greater than "123/zz" before reporting success. This is
> getting pretty klugy though, so cc'ing to pgsql-hackers to see if anyone
> has a better idea.
Hm, instead of "zz" is there a convenient way to find out what actual
character sorts last amongst all the single characters in the locale's
encoding?
Doesn't really strike at the core reason that this is so klugy though. Surely
the "right" thing is to push the concept of open versus closed end-points
through deeper into the estimation logic?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-11-09 00:40:20 | Re: Estimation problem with a LIKE clause containing a / |
| Previous Message | Gregory Stark | 2007-11-08 23:04:40 | Re: Free Space Map thoughts |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2007-11-08 23:24:51 | Re: dell versus hp |
| Previous Message | Steinar H. Gunderson | 2007-11-08 22:51:20 | Re: Join performance |