Re: Some help on buffers and other performance tricks

> The point Gentlemen, was that Good Architecture is King. That's what
I
> was trying to emphasize by calling proper DB architecture step 0. All
> other things being equal (and they usually aren't, this sort of stuff
is
> _very_ context dependent), the more of your critical schema that you
can
> fit into RAM during normal operation the better.
>
> ...and it all starts with proper DB design. Otherwise, you are quite
> right in stating that you risk wasting time, effort, and HW.
>
> Ron

+1!

I answer lots of question on this list that are in the form of 'query x
is running to slow'. Often, the first thing that pops in my mind is
'why are you running query x in the first place?'

The #1 indicator that something is not right is 'distinct' clause.
Distinct (and its evil cousin, union) are often brought in to address
problems.

The human brain is the best optimizer. Even on old hardware the server
can handle a *lot* of data. It's just about where we add
inefficiency...lousy database designs lead to lousy queries or (even
worse) extra application code.

Merlin