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
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
