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

Whilst I admire your purist approach, I would say that if it is
beneficial to performance that a kernel understand drive geometry,
then it is worth investigating teaching it how to deal with that!

I was less referrring to the kernel as I was to the controller.

Lets say we invented a new protocol that including the drive telling
the controller how it was layed out at initialization time so that the
controller could make better decisions about re-ordering seeks. It
would be more cost effective to have that set of electronics just once
in the controller, than 8 times on each drive in an array, which would
yield better performance to cost ratio. Therefore I would suggest it
is something that should be investigated. After all, why implemented
TCQ on each drive, if it can be handled more effeciently at the other
end by the controller for less money?!

Alex Turner
netEconomist

On 4/19/05, Dave Held <dave(dot)held(at)arrayservicesgrp(dot)com> wrote:
> > -----Original Message-----
> > From: Alex Turner [mailto:armtuk(at)gmail(dot)com]
> > Sent: Monday, April 18, 2005 5:50 PM
> > To: Bruce Momjian
> > Cc: Kevin Brown; pgsql-performance(at)postgresql(dot)org
> > Subject: Re: [PERFORM] How to improve db performance with $7K?
> >
> > Does it really matter at which end of the cable the queueing is done
> > (Assuming both ends know as much about drive geometry etc..)?
> > [...]
>
> The parenthetical is an assumption I'd rather not make. If my
> performance depends on my kernel knowing how my drive is laid
> out, I would always be wondering if a new drive is going to
> break any of the kernel's geometry assumptions. Drive geometry
> doesn't seem like a kernel's business any more than a kernel
> should be able to decode the ccd signal of an optical mouse.
> The kernel should queue requests at a level of abstraction that
> doesn't depend on intimate knowledge of drive geometry, and the
> drive should queue requests on the concrete level where geometry
> matters. A drive shouldn't guess whether a process is trying to
> read a file sequentially, and a kernel shouldn't guess whether
> sector 30 is contiguous with sector 31 or not.
>
> __
> David B. Held
> Software Engineer/Array Services Group
> 200 14th Ave. East, Sartell, MN 56377
> 320.534.3637 320.253.7800 800.752.8129
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>