Re: Any better plan for this query?.. - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Any better plan for this query?..
Date
Msg-id b42b73150905190605r3cf1dc06sfe95c7a402813fa8@mail.gmail.com
Whole thread Raw
In response to Re: Any better plan for this query?..  (Dimitri <dimitrik.fr@gmail.com>)
Responses Re: Any better plan for this query?..
List pgsql-performance
On Mon, May 18, 2009 at 6:32 PM, Dimitri <dimitrik.fr@gmail.com> wrote:
> Thanks Dave for correction, but I'm also curious where the time is
> wasted in this case?..
>
> 0.84ms is displayed by "psql" once the result output is printed, and I
> got similar time within my client (using libpq) which is not printing
> any output..

Using libpq?  What is the exact method you are using to execute
queries...PQexec?  If you are preparing queries against libpq, the
best way to execute queries is via PQexecPrepared.  Also, it's
interesting to see if you can get any benefit from asynchronous
queries (PQsendPrepared), but this might involve more changes to your
application than you are willing to make.

Another note: I would like to point out again that there are possible
negative side effects in using char(n) vs. varchar(n) that IIRC do not
exist in mysql.  When you repeat your test I strongly advise switching
to varchar.

Another question: how exactly are you connecting to the database?
local machine? if so, domain socket or tcp/ip?  What are you doing
with the results...immediately discarding?

One last thing: when you get access to the server, can you run a
custom format query test from pgbench and compare the results to your
test similarly configured (same number of backends, etc) in terms of
tps?

merlin

pgsql-performance by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Any better plan for this query?..
Next
From: Robert Haas
Date:
Subject: Re: Any better plan for this query?..