Skip site navigation (1) Skip section navigation (2)

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 11:11:08
Message-ID: 38C6354B.D5DE5842@dcsoft.sk (view raw or flat)
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 ...


pgsql-sql by date

Next:From: David CeljuskaDate: 2000-03-08 13:06:49
Subject: Re: [SQL] database with 1000000 rows is very slow
Previous:From: Colin RothnieDate: 2000-03-08 09:12:43
Subject: FW: [SQL] Errors loading null dates in 7.0beta1

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group