Thread: database with 1000000 rows is very slow

Hallo All!

I have database with follow structure:

CREATE TABLE "article" (       "id" character varying(15) NOT NULL,       "obj_kod" character varying(15),
"popis"character varying(80),       "net_price" float4,       "our_price" float4,       "quantity" int2,       "group1"
charactervarying(40) DEFAULT 'ine',       "group2" character varying(40),       "pic1" character varying(10) DEFAULT
'noname.jpg',      "pic2" character varying(10) DEFAULT 'noname.jpg',       "alt1" character varying(15),       "alt2"
charactervarying(15),       "zisk" int2);
 

CREATE UNIQUE INDEX "article_pkey" on "article" using btree ( "id"
"varchar_ops" );

and with 1000000 rows. Postgres deamon run on 2xPentiumII 330Mhz with
SCSI disk where is
this database store. But I think that select * from article where id
like 'something%' is very slow
(some minutes) and query as: select * from article where id='something'
is very slow too.
I don't know where is a problem a I would like optimalise this, but how
can I do it?

When I use hash except btree, query as: select * from article where
id='something' is fast but
select * from article where id='something%' is very slow.

Can I index some columns externaly? For example: psql index database
table col.
Or postgresql make indexes automaticly?

How can I see that postgres use/or no use index on some query? It is
possible?

Thank you every reply,   Davy!

On Sun, 5 Mar 2000, David Celjuska wrote:

> CREATE UNIQUE INDEX "article_pkey" on "article" using btree ( "id"
> "varchar_ops" );

> this database store. But I think that select * from article where id
> like 'something%' is very slow (some minutes) and query as: select *
> from article where id='something' is very slow too. I don't know where
> is a problem a I would like optimalise this, but how can I do it?

If you haven't run vacuum analyze lately then you should do that.

> When I use hash except btree, query as: select * from article where
> id='something' is fast but select * from article where id='something%'
> is very slow.

Yup. That's because hashes only work on exact matches and btrees can do
ordering (like 'somethink' is surely "larger" than 'something%').

> Or postgresql make indexes automaticly?

No, you have to make them, but you did that right.

> How can I see that postgres use/or no use index on some query? It is
> possible?

Yup. EXPLAIN SELECT ....

In fact, if you can't make any progress you should always accompany any
optimizer issues with the EXPLAIN output. That will help our optimizer
gurus. :)


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden