Re: More Performance

From: "Matthias Urlichs" <smurf(at)noris(dot)net>
To: Mike Mascari <mascarm(at)mascari(dot)com>
Cc: Matthias Urlichs <smurf(at)noris(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: More Performance
Date: 2000-05-20 18:54:20
Message-ID: 20000520205420.D11220@noris.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Hi,

I've found another one of these performance problems in the benchmark,
related to another ignored index.

The whole thing works perfectly after a VACUUM ANALYZE on the
table.

IMHO this is somewhat non-optimal. In the absence of information
to the contrary, PostgreSQL should default to using an index if
it might be appropriate, not ignore it.

I am thus throwing away yet another benchmark run -- the query now runs
300 times faster. *Sigh*

test=# vacuum bench1;
VACUUM
test=# \d bench1
Table "bench1"
Attribute | Type | Modifier
-----------+----------+----------
id | integer | not null
id2 | integer | not null
id3 | integer | not null
dummy1 | char(30) |
Indices: bench1_index_,
bench1_index_1

test=# \d bench1_index_

Index "bench1_index_"
Attribute | Type
-----------+---------
id | integer
id2 | integer
unique btree

test=#
test=#
test=# \d bench1_index_1
Index "bench1_index_1"
Attribute | Type
-----------+---------
id3 | integer
btree

test=# explain update bench1 set dummy1='updated' where id=150;
NOTICE: QUERY PLAN:

Seq Scan on bench1 (cost=0.00..6843.00 rows=3000 width=18)

EXPLAIN
test=# vacuum bench1;
VACUUM
test=# explain update bench1 set dummy1='updated' where id=150;
NOTICE: QUERY PLAN:

Seq Scan on bench1 (cost=0.00..6843.00 rows=3000 width=18)

EXPLAIN
test=# select count(*) from bench1;
count
--------
300000
(1 row)

test=# select count(*) from bench1 where id = 150;
count
-------
1
(1 row)

test=# explain select count(*) from bench1 where id = 150;
NOTICE: QUERY PLAN:

Aggregate (cost=6850.50..6850.50 rows=1 width=4)
-> Seq Scan on bench1 (cost=0.00..6843.00 rows=3000 width=4)

EXPLAIN

***************************************************************

Related to this:

test=# explain select id from bench1 order by id;
NOTICE: QUERY PLAN:

Sort (cost=38259.21..38259.21 rows=300000 width=4)
-> Seq Scan on bench1 (cost=0.00..6093.00 rows=300000 width=4)

EXPLAIN

The basic idea to speed this one up (a lot...) would be to walk the index.

This is _after_ ANALYZE, of course.

--
Matthias Urlichs | noris network GmbH | smurf(at)noris(dot)de | ICQ: 20193661
The quote was selected randomly. Really. | http://smurf.noris.de/
--
To be positive: To be mistaken at the top of one's voice.
-- Ambrose Bierce, The Devil's Dictionary

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2000-05-20 18:56:36 Re: Performance (was: The New Slashdot Setup (includes MySql server))
Previous Message Matthias Urlichs 2000-05-20 18:17:10 Re: Performance (was: The New Slashdot Setup (includes MySql server))

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-05-20 18:56:36 Re: Performance (was: The New Slashdot Setup (includes MySql server))
Previous Message Matthias Urlichs 2000-05-20 18:17:10 Re: Performance (was: The New Slashdot Setup (includes MySql server))