Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] One large v. many small

From: "Gregory Wood" <gregw(at)com-stock(dot)com>
To: "Jeff" <threshar(at)torgo(dot)978(dot)org>
Cc: "PostgreSQL-General" <pgsql-general(at)postgresql(dot)org>
Subject: Re: [PERFORM] One large v. many small
Date: 2003-01-30 19:48:16
Message-ID: 016b01c2c898$891d05c0$ (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-performance
> imagine this scenario using your
> methods (with a wonderful pg performance problem in hand (unless you are
> running cvs))


> 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).


In response to


pgsql-performance by date

Next:From: Neil ConwayDate: 2003-01-30 23:18:54
Subject: Re: Postgres 7.3.1 poor insert/update/search performance
Previous:From: Chad ThompsonDate: 2003-01-30 19:43:09
Subject: Re: One large v. many small

pgsql-general by date

Next:From: Bruno Wolff IIIDate: 2003-01-30 19:55:57
Subject: Re: Documentation needs significant improvement
Previous:From: Chad ThompsonDate: 2003-01-30 19:43:09
Subject: Re: One large v. many small

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group