Re: ~* + LIMIT => infinite time?

From: <typea(at)l-i-e(dot)com>
To: <hannu(at)tm(dot)ee>
Cc: <typea(at)l-i-e(dot)com>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: ~* + LIMIT => infinite time?
Date: 2002-12-16 08:21:14
Message-ID: 61988.12.249.229.112.1040026874.squirrel@www.l-i-e.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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!

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message typea 2002-12-16 10:20:27 Re: ~* + LIMIT => infinite time?
Previous Message Hannu Krosing 2002-12-16 00:03:54 Re: ~* + LIMIT => infinite time?