Re: ~* + LIMIT => infinite time?
От | |
---|---|
Тема | Re: ~* + LIMIT => infinite time? |
Дата | |
Msg-id | 61988.12.249.229.112.1040026874.squirrel@www.l-i-e.com обсуждение исходный текст |
Ответ на | Re: ~* + LIMIT => infinite time? (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: ~* + LIMIT => infinite time?
Re: ~* + LIMIT => infinite time? |
Список | pgsql-performance |
> Have you tried using DECLARE CURSOR...; FETCH 1; CLOSE CURSOR; instead > of LIMIT ? I think I did, in the monitory, and it worked fine. > I tested (part of) it on 7.3 , had to manually change ::int to > case-when-then-else-end as there is no cast from bool to int in7.3 An upgrade to 7.3 has, in fact, gotten rid of that bug... Though now I'm forced to use localhost for connecting, since: A) Upon boot, I'm told I can't use password or crypt, but B) When trying to connect, I can't use md5 C) the passwords get turned into md5 whether I like it or not What's up with all that? I also don't understand why the incredibly useful function I had to auto-typecast from bool to int won't work using ::int syntax, but will if I use int4(...) syntax. Grrr. And breaking the LIMIT x, y thing was annoying. Oh well. I can move forward with some changes in the way we do things. Now that the query runs, I can start in on the optimization again :-) THANKS ALL!!! Oh, and the lower(field) LIKE is MySQL compatible, but I don't think MySQL has an ILIKE... We're abandoning the MySQL support now anyway, since we NEED performance way more than we need MySQL compatibility. Thanks again!
В списке pgsql-performance по дате отправления: