From: Tom Lane <tgl@sss.pgh.pa.us>
To: belal <belalhamed@gmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Copy command Faster than original select
In-reply-to: <1423211439320-5836886.post@n5.nabble.com>
References: <1423211439320-5836886.post@n5.nabble.com>
Comments: In-reply-to belal <belalhamed@gmail.com>
 message dated "Fri, 06 Feb 2015 01:30:39 -0700"
Date: Fri, 06 Feb 2015 10:48:32 -0500
Message-ID: <26997.1423237712@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

belal <belalhamed@gmail.com> writes:
> I made complex select using PGAdmin III Query Editor, Postgre server 9.3
> select ... from mytable join .. join ... order by ....
> I get [Total query runtime: 8841 ms. 43602 rows retrieved.]

> but when I use 
> copy ([same above select]) to '/x.txt' 
> I get [Query returned successfully: 43602 rows affected, 683 ms execution
> time.]

> these test made on the same machine as the postgresql server.

> can anyone explain huge difference in executing time?

It's the time needed for PGAdmin to receive and display 43602 data rows,
likely.  PGAdmin has a reputation of not being too speedy at that.

You could check this by trying some other client such as psql.  Even
in psql, the formatting options you use can make a very large difference
in how fast it is.  However, I think psql's \timing option measures just
the server roundtrip time and not the time taken after that to format and
display the query result.  PGAdmin is probably measuring the query time
differently.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance