Date: Fri, 6 Feb 2015 05:27:31 -0700 (MST)
From: Belal Al-Hamed <belalhamed@gmail.com>
To: pgsql-performance@postgresql.org
Message-ID: <1423225651639-5836917.post@n5.nabble.com>
In-Reply-To: 
 <CAJghg4+2m=Pv5_62Wqtk+Rpgbs0FaAL69edBfk08qZA9O_H_UA@mail.gmail.com>
References: <1423211439320-5836886.post@n5.nabble.com>
 <CAFj8pRDkenXG8-cAMuGNgyjoR9Ne+RRA5xdz1DWiuLqWDdKX7g@mail.gmail.com>
 <1423212269828-5836890.post@n5.nabble.com>
 <CAJghg4+2m=Pv5_62Wqtk+Rpgbs0FaAL69edBfk08qZA9O_H_UA@mail.gmail.com>
Subject: Re: Copy command Faster than original select
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

"so bottle neck have to be some where between client and server"
that's  what I need to know !
where is the bug to made this performance

"Can you try again but with EXPLAIN *ANALYZE* (not only EXPLAIN)?"
it's not a matter of plan problem  I think, it's related to sending data
from server to client, perhaps in allocating buffers for data or problem in
libpq I don't know ...
because why it's super fast exporting same select to file using copy
command.
again I am using the same pc of the postgresql server

regards to all


--
View this message in context: http://postgresql.nabble.com/Copy-command-Faster-than-original-select-tp5836886p5836917.html
Sent from the PostgreSQL - performance mailing list archive at Nabble.com.


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