Re: query slows down drastically with increased number of

Thanks for all the feedback, folks.

Running explain analyze (see below) I get results similar to Tom Lane,
where the 2 queries run at the same speed.
And running in psql (see below) we see the expected speed degradation
for multiple fields, although concatenation is not getting us any
advantage.

----------------------------------------------------------------------
=== RUNNING EXPLAIN ANALYZE ===
----------------------------------------------------------------------

ot6_tdarci=# explain analyze select p.opid from ott_op p;

QUERY PLAN

------------------------------------------------------------------------
------------------------------------------------------
Seq Scan on ott_op p (cost=100000000.00..100002654.44 rows=114344
width=4) (actual time=0.008..260.739 rows=114344 loops=1)
Total runtime: 472.833 ms

Time: 473.240 ms

ot6_tdarci=# explain analyze select p.opid, p.opid, p.opid, p.opid,
p.opid, p.opid, p.opid, p.opid, p.opid, p.opid from ott_op p;

QUERY PLAN

------------------------------------------------------------------------
------------------------------------------------------
Seq Scan on ott_op p (cost=100000000.00..100002654.44 rows=114344
width=4) (actual time=0.006..260.795 rows=114344 loops=1)
Total runtime: 472.980 ms

Time: 473.439 ms

----------------------------------------------------------------------
=== RUNNING THE QUERIES ===
----------------------------------------------------------------------

ot6_tdarci=# \o /dev/null

ot6_tdarci=# select p.opid from ott_op p;
Time: 157.419 ms

ot6_tdarci=# select p.opid, p.opid, p.opid, p.opid, p.opid, p.opid,
p.opid, p.opid, p.opid, p.opid from ott_op p;
Time: 659.505 ms

ot6_tdarci=# select p.opid || p.opid || p.opid || p.opid || p.opid ||
p.opid || p.opid || p.opid || p.opid || p.opid from ott_op p;
Time: 672.113 ms

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Thursday, October 26, 2006 2:53 PM
To: Tom Darci
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] 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