Hi Andres,
Good hint!
DBRNWHSB=# COPY (SELECT * FROM my_large) TO '/tmp/somefile';
COPY 73728
Time: 1405.976 ms
DBRNWHSB=# COPY (SELECT * FROM my_large) TO '/tmp/somefile_binary' BINARY ;
COPY 73728
Time: 840.987 ms
DBRNWHSB=# EXPLAIN ANALYZE SELECT * FROM my_large;
Hi,
Forward my question here.
Best regards,
Han
-- Forwarded message --
From: Zhou Han
Date: Wed, Feb 15, 2012 at 3:01 PM
Subject: Re: [HACKERS] client performance v.s. server statistics
To: Amit Kapila
Cc: pgsql-hack...@postgresql.org
Hi,
I have tried unix domain socket and
On Wednesday, February 15, 2012 12:33:13 PM Han Zhou wrote:
> Hi,
>
> To be more specific, I list my calculation here:
> The timing shown in psql may include: plan + execution + copying to
> result set in backend (does this step exist?) + transferring data to
> client via socket.
Correct.
> Then
Hi,
To be more specific, I list my calculation here:
The timing shown in psql may include: plan + execution + copying to
result set in backend (does this step exist?) + transferring data to
client via socket.
Then I want to know what's the time shown in pg_stat_statement and
EXPLAIN ANALYZE in te
Hi Andres,
May you missed my first post, and I paste it here again:
In our environment sequential scanning (select * from ...) for a table
with tens of thousands of record costs 1 - 2 seconds, regardless of
using ODBC driver or the "timing" result shown in psql client (which
in turn, relies on lib
Hi,
On Wednesday, February 15, 2012 11:19:00 AM Zhou Han wrote:
> I have tried unix domain socket and the performance is similar with
> TCP socket. It is MIPS architecture so memory copy to/from kernel can
> occupy much time, and apparently using unit domain socket has no
> difference than TCP in t
Hi,
Forward my question from HACKERS list to here (and added some more notes):
I have tried unix domain socket and the performance is similar with
TCP socket. It is MIPS architecture so memory copy to/from kernel can
occupy much time, and apparently using unit domain socket has no
difference than
