Re: Less is More

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Cc: PostgreSQL <pgsql-general(at)postgresql(dot)org>
Subject: Re: Less is More
Date: 2015-06-22 13:18:53
Message-ID: 21381.1434979133@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
> I have an odd performance quirk I wonder if anyone has any theories for (not a one-time result, table all heated up, etc)

> spain=# explain analyze select way from planet_osm_point; QUERY PLAN
> -----------------------------------------------------------------------------------------------------------------------------
> Seq Scan on planet_osm_point (cost=0.00..37240.97 rows=1748797width=32) (actual time=0.044..813.521 rows=1748797loops=1)
> Total runtime: 902.256 ms
> (2 rows)

> Time: 902.690 ms

> spain=# explain analyze select * from planet_osm_point;
> QUERY PLAN
> ------------------------------------------------------------------------------------------------------------------------------
> Seq Scan on planet_osm_point (cost=0.00..37240.97 rows=1748797width=848) (actual time=0.051..241.413 rows=1748797loops=1)
> Total runtime: 330.271 ms
> (2 rows)

> Time: 331.869 ms

"SELECT *" gets to skip the projection step that is usually needed to
remove unwanted columns from the query result.

Note that neither of these numbers have much to do with the real
time to execute the query and return results to the client. EXPLAIN
ANALYZE doesn't bother to convert the query results to text, much
less do any network I/O.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Leif Gunnar Erlandsen 2015-06-22 13:32:23 cascading replication and replication slots.
Previous Message Paul Ramsey 2015-06-22 13:09:23 Less is More