pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tom Darci <tom@nuws.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: query slows down drastically with increased number of fields
Date: Thu, 26 Oct 2006 17:53:10 -0400
Message-ID: <26066.1161899590@sss.pgh.pa.us> (raw)
In-Reply-To: <6FB011BE26AACD4CB5F2B505AE0BEB2E020B6E86@MI8NYCMAIL05.Mi8.com>
References: <6FB011BE26AACD4CB5F2B505AE0BEB2E020B6E86@MI8NYCMAIL05.Mi8.com>

"Tom Darci" <tom@nuws.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



view thread (6+ messages)  latest in thread

Message-ID: <26066.1161899590@sss.pgh.pa.us>
Permalink:  ../26066.1161899590@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/26066.1161899590@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: tgl@sss.pgh.pa.us, tom@nuws.com
  Subject: Re: query slows down drastically with increased number of fields
  In-Reply-To: <26066.1161899590@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox