performance and number of selected columns

Hi,

say I have three tables a,b,c with lots of columns (say 10 for each
table). Using psql command line, why does

SELECT a.*,b.*,c.* FROM a,b,c

takes much more longer (in my specifc case 3 times) than only
selecting one column like

SELECT a.oid, b.oid, c.oid FROM a,b,c.

This is on 7.0. Can I play with buffer sizes? Indexes exist on most
of the columns. Columns in the second line can be arbitrary.

Dirk

Dirk Lutzebaeck writes:
>
> Hi,
>
> say I have three tables a,b,c with lots of columns (say 10 for each
> table). Using psql command line, why does
>
> SELECT a.*,b.*,c.* FROM a,b,c
>
> takes much more longer (in my specifc case 3 times) than only
> selecting one column like
>
> SELECT a.oid, b.oid, c.oid FROM a,b,c.
>
> This is on 7.0. Can I play with buffer sizes? Indexes exist on most
> of the columns. Columns in the second line can be arbitrary.

Two things two add:

- EXPLAIN shosw the same results in both cases
- currently I was working with ~ 500 rows

Dirk

Dirk Lutzebaeck <lutzeb(at)aeccom(dot)com> writes:
> say I have three tables a,b,c with lots of columns (say 10 for each
> table). Using psql command line, why does
> SELECT a.*,b.*,c.* FROM a,b,c
> takes much more longer (in my specifc case 3 times) than only
> selecting one column like
> SELECT a.oid, b.oid, c.oid FROM a,b,c.

I'd guess you are simply looking at the increased time to transfer
the additional data to the frontend, format it for display, etc.
With a pure cartesian-product join like that (no WHERE), the backend
is basically going to be spitting out tuples as fast as it can read
them from disk...

regards, tom lane