Re: How to improve db performance with $7K?

Greg, et al.

I never found any evidence of a "stop and get an intermediate request"
functionality in the TCQ protocol.

IIRC, what is there is

1) Ordered
2) Head First
3) Simple

implemented as choices. *VERY* roughly, that'd be like
(1) disk subsystem satisfies requests as submitted, (2) let's
the "this" request be put at the very head of the per se disk
queue after the currently-running disk request is complete, and
(3) is "let the per se disk and it's software reorder the requests
on-hand as per it's onboard software". (N.B. in the last, it's
the DISK not the controller making those decisions). (N.B. too, that
this last is essentially what NCQ (cf. TCQ) is doing )

I know we've been batting around a hypothetical case of SCSI
where it "stops and gets smth. on the way", but I can find
no proof (yet) that this is done, pro forma, by SCSI drives.

In other words, SCSI is a necessary, but not sufficient cause
for intermediate reading.

FWIW

- Ross

-----Original Message-----
From: pgsql-performance-owner(at)postgresql(dot)org [mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Greg Stark
Sent: Friday, April 15, 2005 2:02 PM
To: Tom Lane
Cc: Kevin Brown; pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] How to improve db performance with $7K?

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Yes, you can probably assume that blocks with far-apart numbers are
> going to require a big seek, and you might even be right in supposing
> that a block with an intermediate number should be read on the way.
> But you have no hope at all of making the right decisions at a more
> local level --- say, reading various sectors within the same cylinder
> in an optimal fashion. You don't know where the track boundaries are,
> so you can't schedule in a way that minimizes rotational latency.
> You're best off to throw all the requests at the drive together and
> let the drive sort it out.

Consider for example three reads, one at the beginning of the disk, one at the very end, and one in the middle. If the three are performed in the logical order (assuming the head starts at the beginning), then the drive has to seek, say, 4ms to get to the middle and 4ms to get to the end.

But if the middle block requires a full rotation to reach it from when the head arrives that adds another 8ms of rotational delay (assuming a 7200RPM drive).

Whereas the drive could have seeked over to the last block, then seeked back in 8ms and gotten there just in time to perform the read for free.

I'm not entirely convinced this explains all of the SCSI drives' superior performance though. The above is about a worst-case scenario. should really only have a small effect, and it's not like the drive firmware can really schedule things perfectly either.

I think most of the difference is that the drive manufacturers just don't package their high end drives with ATA interfaces. So there are no 10k RPM ATA drives and no 15k RPM ATA drives. I think WD is making fast SATA drives but most of the manufacturers aren't even doing that.

--
greg

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend