Re: sql query not using indexes

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.
>
>
>

In response to

Browse pgsql-sql by date

  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?]