From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Shouldn't the planner have a higher cost for reverse index scans? |
Date: | 2009-04-10 06:43:01 |
Message-ID: | 49DEEA75.3060008@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
All,
I was looking at these IOZone results for some NAS hardware and thinking
about index scans:
Children see throughput for 6 readers = 72270.04 KB/sec
Parent sees throughput for 6 readers = 72269.06 KB/sec
Min throughput per process = 11686.53 KB/sec
Max throughput per process = 12506.65 KB/sec
Avg throughput per process = 12045.01 KB/sec
Min xfer = 3919344.00 KB
Children see throughput for 6 reverse readers = 17313.57 KB/sec
Parent sees throughput for 6 reverse readers = 17313.52 KB/sec
Min throughput per process = 2569.21 KB/sec
Max throughput per process = 3101.18 KB/sec
Avg throughput per process = 2885.60 KB/sec
Min xfer = 3474840.00 KB
Now, what that says to me is that for this system reverse sequential
reads are 1/4 the speed of forwards reads. And from my testing
elsewhere, that seems fairly typical of disk systems in general.
Now, while index scans (for indexes on disk) aren't 100% sequential
reads, it seems like we should be increasing (substantially) the
estimated cost of reverse index scans if the index is likely to be on
disk. No?
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz *EXTERN* | 2009-04-10 06:47:30 | Re: linux deadline i/o elevator tuning |
Previous Message | Mark Kirkwood | 2009-04-10 06:26:58 | Re: Using IOZone to simulate DB access patterns |