Re: ~* + LIMIT => infinite time? - Mailing list pgsql-performance

From
Subject Re: ~* + LIMIT => infinite time?
Date
Msg-id 61988.12.249.229.112.1040026874.squirrel@www.l-i-e.com
Whole thread Raw
In response to Re: ~* + LIMIT => infinite time?  (Hannu Krosing <hannu@tm.ee>)
Responses Re: ~* + LIMIT => infinite time?  (<typea@l-i-e.com>)
Re: ~* + LIMIT => infinite time?  ("Josh Berkus" <josh@agliodbs.com>)
List 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 by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: ~* + LIMIT => infinite time?
Next
From:
Date:
Subject: Re: ~* + LIMIT => infinite time?