Gregory Stark wrote:
"Luke Lonergan" <llonergan@greenplum.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@mielke.cc>