Hi friend I Want to ask, is there any solutions or tools for monitoring memory
performance in postgre automatically, for example, will send allert if
Peformance memory has exceeded 90%
thank you for your help
07.06.11 00:45, Josh Berkus написав(ла):
All,
Just got this simple case off IRC today:
8.4.4
This plan completes in 100ms:
Filter: (NOT (hashed SubPlan 1))
9.0.2
This plan does not complete in 15 minutes or more:
Filter: (NOT (SubPlan 1))
Hashed is the key. Hashed subplans usually
Version: PostgreSQL 8.3.5 (mammoth replicator)
Schema:
CREATE TABLE tdiag (
diag_id integer DEFAULT nextval('diag_id_seq'::text),
create_time timestamp with time zone default now(), /* time this
record
was created */
diag_time timestamp with time zone
On 7/06/2011 3:47 PM, Didik Prasetyo wrote:
Hi friend I Want to ask, is there any solutions or tools for monitoring
memory performance in postgre automatically, for example, will send
allert if Peformance memory has exceeded 90%
Use standard system monitoring tools like Nagios. There is a
Hello
did you run a ANALYZE statement on table tdiag? A statistics are
absolutelly out.
Regards
Pavel Stehule
2011/6/7 anthony.ship...@symstream.com:
Version: PostgreSQL 8.3.5 (mammoth replicator)
Schema:
CREATE TABLE tdiag (
diag_id integer DEFAULT
Version: PostgreSQL 8.3.5 (mammoth replicator)
Schema:
CREATE TABLE tdiag (
diag_id integer DEFAULT nextval('diag_id_seq'::text),
create_time timestamp with time zone default now(), /* time this
record
was created */
diag_time timestamp with time zone
Version: PostgreSQL 8.3.5 (mammoth replicator)
Schema:
CREATE TABLE tdiag (
diag_id integer DEFAULT nextval('diag_id_seq'::text),
create_time timestamp with time zone default now(), /* time
this
record
was created */
diag_time timestamp
On 8/06/2011 12:19 PM, bakkiya wrote:
We have a postgresql 8.3.8 DB which consumes 100% of the CPU whenever we run
any query.
Yep, that's what it's supposed to do if it's not I/O limited. What's the
problem? Is the query taking longer than you think it should to execute?
Do you expect it to
On Wednesday 08 June 2011 02:40, t...@fuzzy.cz wrote:
Hi,
why are you reposting this? Pavel Stehule already recommended you to run
ANALYZE on the tdiag table - have you done that? What was the effect?
The mailing list system hiccupped and I ended up with two posts.
VACUUM ANALYZE was done,