Re: again on index usage - Mailing list pgsql-hackers

From Tom Lane
Subject Re: again on index usage
Date
Msg-id 29287.1010766847@sss.pgh.pa.us
Whole thread Raw
In response to Re: again on index usage  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Responses Re: again on index usage  (Daniel Kalchev <daniel@digsys.bg>)
List pgsql-hackers
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> My preference would actually be a way to make the optimizer
> choose a plan that causes minimal workload, and not shortest runtime 

?? I am not sure that I see the difference.

What I think you are saying is that when there's lots of competing work,
seqscans have less advantage over indexscans because the
sequential-access locality advantage is lost when the disk drive has to
go off and service some other request.  If that's the mechanism, I think
that the appropriate answer is just to reduce random_page_cost.  It's
true that the current default of 4.0 was chosen using measurements on
otherwise-unloaded systems.  If you assume that the system is (a) too
busy to do read-aheads for you, and (b) has to move the disk arm to
service other requests between each of your requests, then it's not
clear that sequential reads have any performance advantage at all :-(.
I don't think I'd go as far as to lower random_page_cost to 1.0, but
certainly there's a case for using an intermediate value.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: why?
Next
From: Don Baccus
Date:
Subject: Re: again on index usage