On Tue, 04 Dec 2007 13:54:15 +0000
Richard Huxton <dev@archonet.com> wrote:
> Always go for the cleaner design. If it turns out that isn't fast
> enough, *then* start worrying about having a bad but faster design.
mmm yeah right. I did express myself badly.
What I mean I've first to know what are the boundaries to know what
a good design is.
I'm ready to refactor... I'd just like to avoid it for ignorance of
common knowledge about good practice.
BTW still a good reading for dev:
http://www.gtsm.com/oscon2004/
> > Most of the documents available are from a sysadmin point of view.
> > That makes me think that unless I write terrible SQL it won't
> > make a big difference and the first place I'll have to look at if
> > the application need to run faster is pg config.
> The whole point of a RDBMS is so that you don't have to worry about
> this. If you have to start tweaking the fine details of these
This will definitively be the last resort. These times you can't wear
so many hats as before.
> Keep your database design clean, likewise with your queries,
> consider whether you can cache certain results and get everything
> working first.
At the end... if you don't look to much to details everything will
reach a defined deterministic state after all ;)
> Note that this is quite old now, so some performance-related
> assumptions will be wrong for current versions of PG.
I noticed. Maybe this will be part of some other question later.
--
Ivan Sergio Borgonovo
http://www.webthatworks.it