On Tue, 04 Dec 2007 13:54:15 +0000 Richard Huxton <dev@xxxxxxxxxxxx> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
