Shouldn't the planner have a higher cost for reverse index scans?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux