Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group