Re: again on index usage

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

In response to

Responses

Browse pgsql-hackers by date

  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?