Re: How many fields in a table are too many

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: btober(at)seaworthysys(dot)com
Cc: scrawford(at)pinpointresearch(dot)com, kleptog(at)svana(dot)org, m_tessier(at)sympatico(dot)ca, pgsql-general(at)postgresql(dot)org
Subject: Re: How many fields in a table are too many
Date: 2003-06-27 02:40:07
Message-ID: 23503.1056681607@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

<btober(at)seaworthysys(dot)com> writes:
>> As long as we are playing "who's is biggest", I have one with 900+
>> attributes (normalized) but there is a big warning - if you have a
>> query that returns hundreds of columns it will be very, very slow.

> Is the SELECT * the only circumstance? That is, if you specify a small
> number of columns, does the response improve even though the table
> actually has that large number of columns but is only be asked to supply
> a column-limited result set?

IIRC, the worst problems that Steve's profile exposed were associated
with large numbers of columns in a SELECT result --- there are some
doubly nested loops that take time O(N^2) in the number of columns.
But I would not be surprised if some of those loops get invoked on the
underlying table, too, depending on what your query looks like exactly.

This is all eminently fixable, it's just a matter of someone finding
some round tuits ... for most people it doesn't seem like a
high-priority problem, since you won't notice it till you get into the
hundreds of columns ...

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2003-06-27 02:47:10 Re: How many fields in a table are too many
Previous Message Tom Lane 2003-06-27 02:31:24 Re: deleting procs