Re: [PERFORM] One large v. many small
От | Gregory Wood |
---|---|
Тема | Re: [PERFORM] One large v. many small |
Дата | |
Msg-id | 016b01c2c898$891d05c0$7889ffcc@comstock.com обсуждение исходный текст |
Ответы |
Re: [PERFORM] One large v. many small
|
Список | pgsql-general |
> imagine this scenario using your > methods (with a wonderful pg performance problem in hand (unless you are > running cvs)) <snip> > If you do a little app tuning (maybe spend 10-30 minutes readig pgsql > archives) you'll learn to rewrite it as an exists query and make it faster > than it ever could have been on the fast hardware. Your example is invalid... you're talking about an implementation detail, not an architectural design issue. I have to agree with the original point... normalize the database into the proper form, then denormalize as necessary to make things perform acceptably. In other words, do things the right way and then muck it up if you have to. While you make an excellent point (i.e. you can't always through hardware, especially excessive hardware at the problem), I would err on the side of doing things the right way. It usually ends up making the software easier to maintain and add to. A poor design to save a few thousand dollars on hardware now can cost many tens of thousands (or more) dollars on programming time down the road. I've seen entirely too many cases where people started thinking about performance before they considered overall design. It almost always ends in disaster (especially since hardware only gets faster over time and software only gets more complex). Greg
В списке pgsql-general по дате отправления: