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

Поиск
Список
Период
Сортировка
От David Celjuska
Тема Re: [SQL] database with 1000000 rows is very slow
Дата
Msg-id 38C65069.4F61F0FC@dcsoft.sk
обсуждение исходный текст
Список 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@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"
charactervarying(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"
charactervarying(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@dcsoft.sk] /(   )\  ^`~'^
... online ANG<->SK slovnik: http://www.dcsoft.sk/slovnik ...


В списке pgsql-sql по дате отправления:

Предыдущее
От: "Ed"
Дата:
Сообщение: Record number...
Следующее
От: David Celjuska
Дата:
Сообщение: Re: [SQL] database with 1000000 rows is very slow