Re: Less is More - Mailing list pgsql-general

From Tom Lane
Subject Re: Less is More
Date
Msg-id 21381.1434979133@sss.pgh.pa.us
Whole thread Raw
In response to Less is More  (Paul Ramsey <pramsey@cleverelephant.ca>)
List pgsql-general
Paul Ramsey <pramsey@cleverelephant.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;                                                        
QUERYPLAN 
>
-----------------------------------------------------------------------------------------------------------------------------
>  Seq Scan on planet_osm_point  (cost=0.00..37240.97 rows=1748797 width=32) (actual time=0.044..813.521
rows=1748797 loops=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=1748797 width=848) (actual time=0.051..241.413
rows=1748797 loops=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


pgsql-general by date:

Previous
From: Paul Ramsey
Date:
Subject: Less is More
Next
From: Tom Lane
Date:
Subject: Re: Re: pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux