Shouldn't the planner have a higher cost for reverse index scans? - Mailing list pgsql-performance

From Josh Berkus
Subject Shouldn't the planner have a higher cost for reverse index scans?
Date
Msg-id 49DEEA75.3060008@agliodbs.com
Whole thread Raw
Responses Re: Shouldn't the planner have a higher cost for reverse index scans?  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

pgsql-performance by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Using IOZone to simulate DB access patterns
Next
From: "Albe Laurenz *EXTERN*"
Date:
Subject: Re: linux deadline i/o elevator tuning