Re: [PERFORM] Copy command Faster than original select

Executing "Select count(a.*) from (select ... from mytable join .. join ... order by ) as a;" Total query runtime: 454 ms. 1 row retrieved. -- View this message in context: http://postgresql.nabble.com/Copy-command-Faster-than-original-select-tp5836886p5837105.html Sent from the Postgre

Re: [PERFORM] Copy command Faster than original select

belal 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 succe

Re: [PERFORM] Copy command Faster than original select

g] On Behalf Of belal Sent: Friday, February 06, 2015 3:31 AM To: pgsql-performance@postgresql.org Subject: [PERFORM] Copy command Faster than original select I made complex select using PGAdmin III Query Editor, Postgre server 9.3 select ... from mytable join .. join ... order by I get [Tota

Re: [PERFORM] Copy command Faster than original select

On Fri, Feb 6, 2015 at 11:39 AM, Belal Al-Hamed wrote: > Let me change my question to this perhaps it would be clearer Perhaps if you answer all the questions asked, we'll be able to spot where is the bottleneck you are seeing. Could be many factors. Best regards, -- Matheus de Oliveira Anali

Re: [PERFORM] Copy command Faster than original select

2015-02-06 14:39 GMT+01:00 Belal Al-Hamed : > Let me change my question to this perhaps it would be clearer > > why writing data result of select statment from PG server to file on disk > using copy statement is much faster than getting same data through PGAdmin > via libpg on the same PC on the s

Re: [PERFORM] Copy command Faster than original select

Let me change my question to this perhaps it would be clearer why writing data result of select statment from PG server to file on disk using copy statement is much faster than getting same data through PGAdmin via libpg on the same PC on the same system on the same connection (localhost) ? --

Re: [PERFORM] Copy command Faster than original select

On Fri, Feb 6, 2015 at 10:27 AM, Belal Al-Hamed wrote: > "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 > > Did you executed it from psql? Tried with \copy also? (sorry if you answered it already and I

Re: [PERFORM] Copy command Faster than original select

"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

Re: [PERFORM] Copy command Faster than original select

On Fri, Feb 6, 2015 at 6:44 AM, Belal Al-Hamed wrote: > > but isn't copy use the same plan ??? > > any way this is the query play > > "Sort (cost=15402.76..15511.77 rows=43602 width=184)" > Can you try again but with EXPLAIN *ANALYZE* (not only EXPLAIN)? Best regards, -- Matheus de Oliveira A

Re: [PERFORM] Copy command Faster than original select

2015-02-06 10:50 GMT+01:00 Belal Al-Hamed : > fast as > > Query returned successfully: 43602 rows affected, 1089 ms execution time. > so bottle neck have to be some where between client and server Pavel > > > > -- > View this message in context: > http://postgresql.nabble.com/Copy-command-Fas

Re: [PERFORM] Copy command Faster than original select

fast as Query returned successfully: 43602 rows affected, 1089 ms execution time. -- View this message in context: http://postgresql.nabble.com/Copy-command-Faster-than-original-select-tp5836886p5836902.html Sent from the PostgreSQL - performance mailing list archive at Nabble.com. -- Sent

Re: [PERFORM] Copy command Faster than original select

2015-02-06 10:15 GMT+01:00 Belal Al-Hamed : > "this slowdown can be enforced by slow client (or slow network)." > As I said i made the tow test on the same machine as the server using > PGAdmin no network involved. > > "pgAdmin is not terrible fast" > I also try the same query from my application

Re: [PERFORM] Copy command Faster than original select

"this slowdown can be enforced by slow client (or slow network)." As I said i made the tow test on the same machine as the server using PGAdmin no network involved. "pgAdmin is not terrible fast" I also try the same query from my application using libpq I get same results regards -- View this

Re: [PERFORM] Copy command Faster than original select

2015-02-06 9:44 GMT+01:00 Belal Al-Hamed : > thanks, > > but isn't copy use the same plan ??? > aha - I was wrong, this slowdown can be enforced by slow client (or slow network). pgAdmin is not terrible fast. Try to execute your query from psql. Regards Pavel > > any way this is the query pl

Re: [PERFORM] Copy command Faster than original select

thanks, but isn't copy use the same plan ??? any way this is the query play "Sort (cost=15402.76..15511.77 rows=43602 width=184)" " Output: "Sessions"."SesUser", "Vouchers"."VouID", "Journals"."JurMuniment", "Journals"."JurRefID", "Journals"."JurDate", "Vouchers"."VouJournal", "Vouchers"."VouM

Re: [PERFORM] Copy command Faster than original select

Hi 2015-02-06 9:30 GMT+01:00 belal : > 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

[PERFORM] Copy command Faster than original select

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 aff