Re: Any better plan for this query?..

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Any better plan for this query?..
Дата
Msg-id b42b73150905190605r3cf1dc06sfe95c7a402813fa8@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Any better plan for this query?..  (Dimitri <dimitrik.fr@gmail.com>)
Ответы Re: Any better plan for this query?..  (Dimitri <dimitrik.fr@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Any better plan for this query?..
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Any better plan for this query?..