From: | "Mitch Vincent" <mitch(at)venux(dot)net> |
---|---|
To: | "pgsql-sql" <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: sql query not using indexes |
Date: | 2000-09-20 18:37:07 |
Message-ID: | 008401c02331$c83e7540$0200000a@doot |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
I'm curious, I know PG doesn't have support for 'full' text indexing so I'm
wondering at what point does indexing become ineffective with text type
fields?
-Mitch
----- Original Message -----
From: "Stephan Szabo" <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: "User Lenzi" <lenzi(at)k1(dot)com(dot)br>
Cc: "pgsql-sql" <pgsql-sql(at)postgresql(dot)org>
Sent: Wednesday, September 20, 2000 11:23 AM
Subject: Re: [SQL] sql query not using indexes
> On Wed, 20 Sep 2000, User Lenzi wrote:
>
> > if I start a query:
> >
> > explain select * from teste where login = 'xxx'
> > results:
> > Index Scan using teste1 on teste (cost=0.00..97.88 rows=25 )
> >
> >
> > however a query:
> > explain select * from teste where login > 'AAA'
> > results:
> > Seq Scan on teste ....
> >
> >
> > On a machine running version 6.5 both queries results index scan.
> >
> > this results that the version 6.5 is faster than version 7.0.2 on this
> > kind of
> > query.
> >
> >
> > Any explanation???
>
> Have you done a vacuum analyze on the table? Also, what does the row
> count for the second query look like? It's probably deciding that
> there are too many rows that will match login >'AAA' for index scan
> to be cost effective. So, actually, also, what does
> select count(*) from teste where login>'AAA" give you on the 7.0.2 box.
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2000-09-21 01:29:54 | Re: [Fwd: Re: no ORDER BY in subselects?] |
Previous Message | Louis-David Mitterrand | 2000-09-20 18:25:56 | Re: [Fwd: Re: no ORDER BY in subselects?] |