From: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
---|---|
To: | Cris <cris(at)dmcid(dot)net> |
Cc: | <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Index not used, |
Date: | 2003-04-09 18:56:06 |
Message-ID: | 20030409115454.P68720-100000@megazone23.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-jdbc |
On Wed, 9 Apr 2003, Cris wrote:
> I've have this table:
>
> TABLE BB : There isn't any primary key, and is it more or less order (I mean, tt always is increased in each row, and id is
> nearly ordered)
> ex:
>
> id, op, atr, tt
>
> 1 0 X, 1
> 2 0 A 3
> 3 0 X 5
> ..........
> 1 0 X 51
> .......
> 85 1 l 150
> 86 2 po 155
> 2 0 X 178
> 87 3 1 189
> ....
>
> I VACUUM ANALYZE each 10.000 inserts more or less
> in my case op only can have 3 values;
> I've created an index on (id,op,tt) to improve the next query, that is executed very often:
> "SELECT * FROM BB WHERE id="+ id+" AND op=0 order by tt desc;";
> (because the only row I need is the one that has the highest tt)
You might want to use limit 1 then to prevent it from getting all the rest
of the rows as well.
> but, after an hour running the program (more than 90.000 rows), I stopped it and
> "EXPAIN SELECT * FROM BB WHERE id="+ id+" AND op=0 order by tempst desc;";
> But, my sorprise was that the index wasn't be used. Always do a Seq Scan.
What is the actual explain output?
From | Date | Subject | |
---|---|---|---|
Next Message | Chris White | 2003-04-09 18:59:08 | Re: [JDBC] Problems with Large Objects using Postgres 7.2.1 |
Previous Message | blugering | 2003-04-09 18:36:22 | Install ODBC Does Not Work |
From | Date | Subject | |
---|---|---|---|
Next Message | Chris White | 2003-04-09 18:59:08 | Re: [JDBC] Problems with Large Objects using Postgres 7.2.1 |
Previous Message | Tom Lane | 2003-04-09 17:28:21 | Re: [JDBC] Problems with Large Objects using Postgres 7.2.1 |