Re: query slows down drastically with increased number of fields

"Tom Darci" <tom(at)nuws(dot)com> writes:
> It runs in about half a second (running in PgAdmin... the query run
> time, not the data retrieval time)

I don't have a lot of faith in PgAdmin's ability to distinguish the two.
In fact, for a query such as you have here that's just a bare seqscan,
it's arguably *all* data retrieval time --- the backend will start
emitting records almost instantly.

FWIW, in attempting to duplicate your test I get

regression=# explain analyze select f1 from foo;
QUERY PLAN
------------------------------------------------------------------------------------------------------------
Seq Scan on foo (cost=0.00..1541.00 rows=100000 width=4) (actual time=0.161..487.192 rows=100000 loops=1)
Total runtime: 865.454 ms
(2 rows)

regression=# explain analyze select f1,f1,f1,f1,f1,f1,f1,f1,f1,f1,f1 from foo;
QUERY PLAN
------------------------------------------------------------------------------------------------------------
Seq Scan on foo (cost=0.00..1541.00 rows=100000 width=4) (actual time=0.169..603.795 rows=100000 loops=1)
Total runtime: 984.124 ms
(2 rows)

Note that this test doesn't perform conversion of the field values to
text form, so it's an underestimate of the total time spent by the
backend for the real query. But I think almost certainly, your speed
difference is all about having to send more values to the client.
The costs not measured by the explain-analyze scenario would scale darn
near linearly with the number of repetitions of f1.

regards, tom lane