Added to TODO:
* Improve performance for queries with many columns
We already have an item for tables with many columsn.
---------------------------------------------------------------------------
Tom Lane wrote:
> <[EMAIL PROTECTED]> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
