Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1

Gregory Stark wrote:
> "Luke Lonergan" <llonergan(at)greenplum(dot)com> writes:
>
>> Increasing the number of disks in a RAID actually makes the number higher,
>> not lower. Until Postgres gets AIO + the ability to post multiple
>> concurrent IOs on index probes, random IO does not scale with increasing
>> disk count, but sequential does, thus the increasing "random page cost" as
>> the RAID gets faster.
>>
> What I don't understand is the bit about "until Postgres gets AIO + the
> ability to post multiple concurrent IOs on index probes". Even with AIO your
> seek times are not going to be improved by wide raid stripes. And you can't
> possibly find the page at level n+1 before you've looked at the page at level
> n. Do you mean to be able to probe multiple index keys simultaneously? How
> does that work out
One suggestion: The plan is already in a tree. With some dependency
analysis, I assume the tree could be executed in parallel (multiple
threads or event triggered entry into a state machine), and I/O to fetch
index pages or table pages could be scheduled in parallel. At this
point, AIO becomes necessary to let the underlying system (and hardware
with tagged queueing?) schedule which pages should be served best first.

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>