Chris wrote:
> I have a lot of centos servers which are running postgres. Postgres isn't
> used
> that heavily on any of them, but lately, the stats collector process keeps
> causing tons of IO load. It seems to happen only on servers with centos 5.
Does this correlate to an increase in size of
Brian Cox writes:
> On 04/10/2010 12:29 AM, Tom Lane [...@sss.pgh.pa.us] wrote:
>> but anyway: the main
>> known cause for that is if one of the tables used in the query got
>> dropped (by another session) just after the query started. Could
>> that have happened to you?
> interesting and possibl
2010/4/13 Chris :
> I have a lot of centos servers which are running postgres. Postgres isn't
> used
> that heavily on any of them, but lately, the stats collector process keeps
> causing tons of IO load. It seems to happen only on servers with centos 5.
> The versions of postgres that are runni
How do you explain the cost is about ten times lower in the 2nd query
than the first ?
Function call cost ?
Can you EXPLAIN ANALYZE ?
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
I'm also wondering if a re-clustering of the table would work based on
the index that's used.
such that:
CLUSTER core_object USING plugins_plugin_addr_oid_id;
and see if that makes any change in the differences that your seeing.
On 04/13/2010 02:24 PM, Kevin Grittner wrote:
> norn wrote:
>
>
norn wrote:
> I am wondering why there are so big gap between two limits and how
> to avoid this...
I think we've already established that it is because of the
percentage of the table which must be scanned to get to the desired
number of rows. The problem is exacerbated by the fact that it's
I have a lot of centos servers which are running postgres. Postgres isn't used
that heavily on any of them, but lately, the stats collector process keeps
causing tons of IO load. It seems to happen only on servers with centos 5.
The versions of postgres that are running are:
8.1.18
8.2.6
8.3.1
8
On Apr 13, 5:28 am, kevin.gritt...@wicourts.gov ("Kevin Grittner")
wrote:
> The cost settings help the optimizer make good decisions about plan
> choice. I guess I don't have much reason to believe, at this point,
> that there is a better plan for it to choose for this query. Do you
> think you s
Hi there,
I have a simple aggregate query: SELECT count("PK_ID") AS "b1" FROM "tbA"
WHERE "PK_ID" > "f1"( 'c1' ), which has the following execution plan:
"Aggregate (cost=2156915.42..2156915.43 rows=1 width=4)"
" -> Seq Scan on "tbA" (cost=0.00..2137634.36 rows=7712423 width=4)"
"Filt
