Re: [PERFORM] Estimation problem with a LIKE clause containing a /

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PERFORM] Estimation problem with a LIKE clause containing a /
Дата
Msg-id 27405.1194542548@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: [PERFORM] Estimation problem with a LIKE clause containing a /
Список pgsql-hackers
"Guillaume Smet" <guillaume.smet@gmail.com> writes:
> On Nov 8, 2007 12:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I've applied a patch that might help you:
>> http://archives.postgresql.org/pgsql-committers/2007-11/msg00104.php

> AFAICS, it doesn't seem to fix the problem. I just compiled
> REL8_1_STABLE branch and I still has the following behaviour:

OK, I tried it in fr_FR locale and what I find is that

regression=# select '123/' < '1230'::text;
 ?column?
----------
 t
(1 row)

so make_greater_string() will still think that its first try at
generating an upper-bound string is good enough.  However

regression=# select '123/1' < '1230'::text;
 ?column?
----------
 f
(1 row)

so the data starting with '123/' is still outside the generated range,
leading to a wrong estimate.  I didn't see this behavior yesterday but
I was experimenting with en_US which I guess has different rules.

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.

            regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: A small rant about coding style for backend functions
Следующее
От: "Brendan Jurd"
Дата:
Сообщение: Re: A small rant about coding style for backend functions