Hi, this question is mostly born of curiosity: when monitoring our
database I often use the following queries to get a current query count
and listing of individual queries:
select count(*)
from pg_stat_activity
where current_query not ilike '<idle>';
select procpid, (now() - query_start) as query_time, client_addr as
client_host, current_query
from pg_stat_activity
where current_query not ilike '<idle>'
--and procpid=4452
--and currrent_query ilike ' '
order by (now() - query_start) desc;
Before migrating to 8.2, even during peak times, unless queries were
seriously stacking (not completing in a timely manner), we'd see at most
50 - 100 queries active at any given time (we did have
stats_command_string = on). Since the migration, during peak times it's
not uncommon to see the query count vary radically between around 80 and
the upper 400s (we have max_connections set to 512). This variation is
per second and when the count is high, the vast majority listed are
sub-second. It would seem that this is due to some fine tuning
somewhere on th backside of 8.2 versus previous versions. Was there
previously a more limited precision to the query lengths that would be
picked up by the pg_stat_activity view?
--
erik jones <[EMAIL PROTECTED]>
software development
emma(r)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
