From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Daniel Kalchev" <daniel(at)digsys(dot)bg>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: again on index usage |
Date: | 2002-01-11 16:34:07 |
Message-ID: | 29287.1010766847@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 2002-01-11 16:41:11 | Re: again on index usage |
Previous Message | Vince Vielhaber | 2002-01-11 15:54:55 | why? |