Re: [SQL] database with 1000000 rows is very slow

From: David Celjuska <dcsoft(at)dcsoft(dot)sk>
To: pgsql-sql(at)postgreSQL(dot)org
Subject: Re: [SQL] database with 1000000 rows is very slow
Date: 2000-03-08 13:06:49
Message-ID: 38C65069.4F61F0FC@dcsoft.sk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Hello Peter Eisentraut!

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

Ok, I was run it and here is result, but I understand what it means.

Can you explain it to me, please?

[dcsoft(at)bigmax dcsoft]$ vacuumdb --analyze --verbose --table article
evid
NOTICE: --Relation article--
NOTICE: Pages 24341: Changed 0, Reapped 8, Empty 0, New 0; Tup 1376029:
Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 29, MinLen 112, MaxLen 166;
Re-using: Free/Avail. Space 1924/0; EndEmpty/Avail. Pages 0/0. Elapsed
3/246 sec.
NOTICE: Index article_index: Pages 6465; Tuples 1376029: Deleted 0.
Elapsed 1/5 sec.
NOTICE: Index hash_obj_kod: Pages 10841; Tuples 1376029: Deleted 0.
Elapsed 1/25 sec.
NOTICE: Index article_obj_kod_key: Pages 6860; Tuples 1376029: Deleted
0. Elapsed 1/5 sec.
NOTICE: Index article_pkey: Pages 6858; Tuples 1376029: Deleted 0.
Elapsed 1/5 sec.

>> 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%').

Ok, I understand.

>> 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 EXPLAIN progress you should always accompany any
>optimizer issues with the EXPLAIN output. That will help our optimizer
>gurus. :)

OK, My table structure is:

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" character varying(40) DEFAULT 'ine',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" character varying(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" character varying(15),
"zisk" int2);
REVOKE ALL on "article" from PUBLIC;
GRANT INSERT,UPDATE,DELETE,SELECT on "article" to GROUP "evid";
CREATE UNIQUE INDEX "article_pkey" on "article" using btree ( "id"
"varchar_ops" );
CREATE INDEX "article_obj_kod_key" on "article" using btree ( "obj_kod"
"varchar_ops" );
CREATE INDEX "hash_obj_kod" on "article" using hash ( "obj_kod"
"varchar_ops" );
CREATE INDEX "article_index" on "article" using btree ( "obj_kod"
"varchar_ops" );

with 1376029 rows.

and here is result:

evid=> explain select * from article where id = 'something';
NOTICE: QUERY PLAN:

Index Scan using article_pkey on article (cost=2.05 rows=1 width=120)

EXPLAIN

I think that it is ok (fast), but next result is no.

evid=> explain select * from article where id like '186892%';
NOTICE: QUERY PLAN:

Index Scan using article_pkey on article (cost=33333.82 rows=1
width=120)

EXPLAIN

I think that price is very big.

If you can help me or If you have some sugestion please writte me.

With regards,

.~.
/V\ Davy
// \\ [dcsoft(at)dcsoft(dot)sk]
/( )\
^`~'^
... online ANG<->SK slovnik: http://www.dcsoft.sk/slovnik ...

Browse pgsql-sql by date

  From Date Subject
Next Message Ed 2000-03-08 13:43:05 Record number...
Previous Message David Celjuska 2000-03-08 11:11:08 Re: [SQL] database with 1000000 rows is very slow