| From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
|---|---|
| To: | Rajesh Kumar Mallah <mallah(at)trade-india(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Effect of too many columns |
| Date: | 2004-04-12 12:17:40 |
| Message-ID: | 20040412121740.GC20278@wolff.to |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Apr 12, 2004 at 17:24:17 +0530,
Rajesh Kumar Mallah <mallah(at)trade-india(dot)com> wrote:
>
> Greetings,
>
> Is there any performance penalty of having too many columns in
> a table in terms of read and write speeds.
>
> To order to keep operational queries simple (avoid joins) we plan to
> add columns in the main customer dimension table.
>
> Adding more columns also means increase in concurrency in the table
> as more and more applications will access the same table.
>
> Any ideas if its better to split the table application wise or is it ok?
This is normally a bad idea. If you properly implement constraints in
what is effectively a materialized view, you might end up with a slower
system, depending on your mix of queries. (Generally updating will take
more resources.) So you probably want to test your new design under a
simulated normal load to see if it actually speeds things up in your
case before making the change.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-04-12 12:28:19 | Re: Index Backward Scan fast / Index Scan slow ! |
| Previous Message | Rajesh Kumar Mallah | 2004-04-12 11:54:17 | Effect of too many columns |