"Subbiah Stalin-XCGF84" wrote:
> We have found the problem.
Great news!
> Apparently there was a query doing count on 45 million rows table
> run prior to the episode of slow query. Definitely cached data is
> pushed out the memory.
Yeah, that would completely explain your symptoms.
> I
> -Original Message-
> From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
> Sent: Tuesday, August 04, 2009 8:57 AM
> To: Subbiah Stalin-XCGF84; pgsql-performance@postgresql.org
> Subject: RE: [PERFORM] Query help
>
> "Subbiah Stalin-XCGF84" wro
t
get affected by queries like these.
Stalin
-Original Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: Tuesday, August 04, 2009 8:57 AM
To: Subbiah Stalin-XCGF84; pgsql-performance@postgresql.org
Subject: RE: [PERFORM] Query help
"Subbiah Stalin-XCGF84" wr
llect necessary stats on the next occurrence of the slow
query.
Stalin
-Original Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: Tuesday, August 04, 2009 8:57 AM
To: Subbiah Stalin-XCGF84; pgsql-performance@postgresql.org
Subject: RE: [PERFORM] Query help
&qu
"Subbiah Stalin-XCGF84" wrote:
> Server has 32G memory and it's a dedicated to run PG and no other
> application is sharing this database.
It's not likely to help with this particular problem, but it's
generally best to start from a position of letting the optimizer know
what it's really got f
s back to fast
mode. If it had used a different execution plan than the above, how do I
list all execution plans executed for a given SQL.
Thanks,
Stalin
-Original Message-
From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
Sent: Monday, August 03, 2009 1:45 PM
To: Subbiah Stalin-XCGF84; pg
"Subbiah Stalin-XCGF84" wrote:
> Shared buffer=8G, effective cache size=4G.
That is odd; if your shared buffers are at 8G, you must have more than
4G of cache. How much RAM is used for cache at the OS level?
Normally you would add that to the shared buffers to get your
effective cache size,
] Query help
"Subbiah Stalin-XCGF84" wrote:
> Not sure what's wrong in below execution plan but at times the query
> runs for 5 minutes to complete and after a while it runs within a
> second or two.
The plan doesn't look entirely unreasonable for the given qu
"Subbiah Stalin-XCGF84" wrote:
> Not sure what's wrong in below execution plan but at times the query
> runs for 5 minutes to complete and after a while it runs within a
> second or two.
The plan doesn't look entirely unreasonable for the given query,
although it's hard to be sure of that wit
All,
Not sure what's wrong in below execution plan but at times the query
runs for 5 minutes to complete and after a while it runs within a second
or two.
Here is explain analyze out of the query.
SELECT
OBJECTS.ID,OBJECTS.NAME,OBJECTS.TYPE,OBJECTS.STATUS,OBJECTS.ALTNAME,OBJE
CTS.DOMAINID,OBJ
10 matches
Mail list logo
