[Gllug] SQL performance tuning (was: RE: Restore RAID0 /var)

[Walter Stanish]

> Those are actually application tuning, which is rather different to  
> database tuning. Now, the greatest win is usually in application  
> tuning, because you're usually optimising-out long queries, and the  
> fastest query is one that isn't made, but sometimes that's not
> possible.

Thanks for your contribution but:
 - the question *was* asked within the context of
   optimisation for an upcoming web application deployment
 - the initial answer already highlighted the fact that
   some strategies were obviously quicker to implement
   than others
 - there have already been similar follow ups... here's +1...

<whinge at large organisations>
IMHO and IIRC the other poster's, only the poor lost
souls floating about the bureaucracy of large organisations
(often not the case) have to put up with such artificial
distinctions as DBA/webdev/sysadmin roles, commonly they
are the same person.

(Of course, situations where bureaucracy and turf are greater
 decision making constraints than intelligence are real and
 many, but this does not make them a default on which to
 interpret technical discussion, esp. on a technical list!)

Also IMHO at a cultural level, the whole idea of 'not my
problem' and turf-setting isn't a very (hackerly or) 
admirable approach to technical problems, but rather a
terrible shame, in that it artificially limits the curious
mind / motivated programmer!
</whinge at large organisations>

> spindle optimisations: use Pg tablespaces to shuffle
> indices/tables onto other disks 

Interesting.

I'm curious as to what percentage of PgSQL databases you
estimate actually hit the disk for indexes?  I'd have
thought that on the vast majority of web-app backends
indexes will easily fit in memory... and in those 
cases where the database size was so large that this
were impossible, buying more RAM would most often be
a more effective AND cheaper fix (both initial cost
and running costs) than adding disks to the equation.
Maybe I have this one wrong, though.

- Walter
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug