Ref:

http://archives.postgresql.org/pgsql...3/msg00190.php


In the above referenced thread, I bring up an observation re the timing of pgAdmin results. Essentially I observed that the query execution times as reported by pgAdmin "inflate" much more than the data retrieval times.

Per pgAdmin help,

"The status line will show how long the last query took to complete. If a dataset was returned, not only the elapsed time for server execution is displayed, but also the time to retrieve the data from the server to the Data Output page."

I've been told in that thread that pgSQL doesn't track or report the times to execute the query separately than the time to transport the data.

If this is the case, then I would assume that pgAdmin uses the time sent, the time of first data arrival, and the time of query completion to calculate and display the times on the status line.

Is anyone aware of any pgAdmin ideosyncrosy that would explain slow pgAdmin reported execution times when data is transferred over the relatively slow internet?

Thanks

Lou

Lou O'Quin wrote:

> If this is the case, then I would assume that pgAdmin uses the time
> sent, the time of first data arrival, and the time of query completion
> to calculate and display the times on the status line.

We can't know that, because this is hidden in the underlying libpq library.
>
> Is anyone aware of any pgAdmin ideosyncrosy that would explain slow
> pgAdmin reported execution times when data is transferred over the
> relatively slow internet?

On slow machines, the update of the status line may take considerable
time (100 per second), this will be addressed in V1.4. But this has
nothing to do with slow lines.

Regards,
Andreas

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match