Performance Tuning Question

From: Brian Hirt <bhirt(at)mobygames(dot)com>
To: pgsql-general(at)postgresql(dot)org
Cc: Brian Hirt <bhirt(at)mobygames(dot)com>
Subject: Performance Tuning Question
Date: 2002-09-09 05:04:31
Message-ID: 1031547872.1344.698.camel@loopy.tr.berkhirt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I'm looking for some suggestions on database tuning. I've looked on
the postgres site and google and found very little in-depth information
on tuning.

I have a database (7.2.2) that gets a lot of read access and very few
updates/inserts. The server (rh73 dual xeon 2ghz) running this database
has 2gb of memory and is only running postgres. The database itself is
about 1.5gb (via du -sk), with a lot of that 1.5gb not being part of the
active dataset. We find that there is almost no IO on this machine.
The small amount of I/O is because of the infrequent writes and the
aggressive disk caching of the linux kernel.

It seems the planner tries to avoid I/O so much that the default tuning
parameters works against us a bit. i've tried a few changes here and
there, but without much luck since i don't really know what to change
tho values to.

One of the things I see over and over again is the planner picking a seq
scan over an index scan. And practically always, when I force a index
scan and use explain analyze the index scan would have been faster.
I've heard the explanation be that at some point it's cheaper to do a
scan instead of using the index. I think that assumption might be based
on IO estimates.

I can just give one example here that's indicative of what I'm seeing
over and over. The two explain outputs are below, and both are
executing without any I/O. The table has 12904 rows, the plan estimates
959 rows (about 7.4% of table) and actually only 639 (~ 5%) are
fetched. The table scan consistently takes 50 times longer to execute.
I see this over and over and over. I know a few hundred msec here and
there seems small, but this machine is performing at least a few million
queries a day -- it adds up.

Any advice or pointers would be greatly appreciated.

--thanks

basement=# explain analyze select count(*) from game_cover where
cover_scan_of_id = 6;
NOTICE: QUERY PLAN:

Aggregate (cost=1970.70..1970.70 rows=1 width=0) (actual
time=121.07..121.07 rows=1 loops=1)
-> Seq Scan on game_cover (cost=0.00..1968.30 rows=959 width=0)
(actual time=0.13..120.56 rows=639 loops=1)
Total runtime: 121.14 msec

and

basement=# set enable_seqscan TO false;
SET VARIABLE
basement=# explain analyze select count(*) from game_cover where
cover_scan_of_id = 6;
NOTICE: QUERY PLAN:

Aggregate (cost=2490.66..2490.66 rows=1 width=0) (actual
time=2.45..2.45 rows=1 loops=1)
-> Index Scan using game_cover_scan_of on game_cover
(cost=0.00..2488.26 rows=959 width=0) (actual time=0.12..2.03 rows=639
loops=1)
Total runtime: 2.54 msec

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Christoph Dalitz 2002-09-09 08:13:28 OT: mailing list spam protection?
Previous Message Christopher Kings-Lynne 2002-09-09 03:06:21 Re: [HACKERS] Australian Open Source Awards