Re: [SQL] database with 1000000 rows is very slow - Mailing list pgsql-sql
From | David Celjuska |
---|---|
Subject | Re: [SQL] database with 1000000 rows is very slow |
Date | |
Msg-id | 38C65069.4F61F0FC@dcsoft.sk Whole thread Raw |
List | 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 ...