Problems monitoring DB activity

[Doug Y]

Hello,

When I do the following:

SELECT * FROM pg_catalog.pg_stat_activity;

The current_query and query_start columns are always empty. Obviously
this makes it hard to monitor problems with the various admin tools, etc.

I'm guessing there's a setting or something that needs updated, I just
need a point in the right direction. DB is 7.4.2

Thanks

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ***@postgresql.org so that your
message can get through to the mailing list cleanly

[Michael Fuhr]

Post by Doug Y
SELECT * FROM pg_catalog.pg_stat_activity;
The current_query and query_start columns are always empty. Obviously
this makes it hard to monitor problems with the various admin tools, etc.

Does postgresql.conf have stats_command_string = true?

[Doug Y]

Post by Michael Fuhr

Post by Doug Y
SELECT * FROM pg_catalog.pg_stat_activity;
The current_query and query_start columns are always empty. Obviously
this makes it hard to monitor problems with the various admin tools, etc.

Does postgresql.conf have stats_command_string = true?

Thanks, setting that did the trick.... whats the performance hit for
having it enabled?

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Michael Fuhr]

Post by Doug Y

Post by Michael Fuhr
Does postgresql.conf have stats_command_string = true?

Thanks, setting that did the trick.... whats the performance hit for
having it enabled?

I haven't done any tests to determine the performance penalty; maybe
one of the developers or somebody who's done some benchmarks can
comment.

The "Annotated postgresql.conf and Global User Configuration (GUC)
Guide"[1] says that "Enabling statistics collection costs a small
amount of time per query, but is invaluable for debugging and
performance tuning."

[1] http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html

[Goulet, Dick]

Sounds like the Oracle parameter TIMED_STATISTICS. Costs you soo little
in performance, but saves you a pile in troubleshooting. Many DBA's
still set it to false to "save the expense". Nice to know the same
exists here.


Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: Michael Fuhr [mailto:***@fuhr.org]
Sent: Friday, October 08, 2004 11:15 AM
To: Doug Y
Cc: pgsql-***@postgresql.org
Subject: Re: [ADMIN] Problems monitoring DB activity

Post by Doug Y

Post by Michael Fuhr
Does postgresql.conf have stats_command_string = true?

Thanks, setting that did the trick.... whats the performance hit for
having it enabled?

I haven't done any tests to determine the performance penalty; maybe one
of the developers or somebody who's done some benchmarks can comment.

The "Annotated postgresql.conf and Global User Configuration (GUC)
Guide"[1] says that "Enabling statistics collection costs a small amount
of time per query, but is invaluable for debugging and performance
tuning."

[1]
http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend