Re: query execution time

2010.10.06 00:30, Kevin Grittner rašė:
> There can be a number of reasons. The time to transmit the query
> results to the client is one that jumps to mind, if the query
> generates a large result set. Parts of what you described might
> suggest checkpoint issues, depending on the query mix, the
> PostgreSQL version, the hardware and the OS.
Version string: PostgreSQL 8.3.4 on i686-pc-linux-gnu, compiled by GCC
gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2)

> You haven't given us
> enough information to even start to guess which of these or other
> issues might be involved.
Yes, you are right, but there is not much I can send you, because there
are several unrelated queries that act the same way (that is have
"jumping" execution times). If you please see
https://sites.google.com/site/juliaustestukas/Home I think the picture
would explain the problem better then I can... I have put red ellipses
around the times that are too different. Maybe you know what is done
after the query is executed? As I said the traffic limit is not reached.
There must be something else. If there was a hardware issue I guess the
EXPLAIN ANALYZE would show the execution time comparable to the observed
one...
One more thing that may be connected to this - the encoding was changed
for DB using instructions on
http://bryan-murdock.blogspot.com/2008/11/convert-postgresql-database-from-latin1.html
. We converted it to UTF-8 from SQL_ASCII . Manual vacuum was executed
after that. The settings for autovacuum were not changed so it is
enabled by default on every table.
Please, could you provide information what actions does the postgres
take after it does actions monitored by EXPLAIN ANALYZE? Could it be
libpq issue (pgAdmin uses it)?

--
Julius Tuskenis
Programavimo skyriaus vadovas
UAB nSoft
mob. +37068233050