Please have a look at the following explain plan:
explain analyze
select *
from vtiger_crmentity
inner JOIN vtiger_users
ON vtiger_users.id = vtiger_crmentity.smownerid
where vtiger_crmentity.deleted = 0 ;
QUERY
PLAN
On Mon, Feb 15, 2010 at 2:35 AM, AI Rumman rumman...@gmail.com wrote:
Please have a look at the following explain plan:
explain analyze
select *
from vtiger_crmentity
inner JOIN vtiger_users
ON vtiger_users.id = vtiger_crmentity.smownerid
where vtiger_crmentity.deleted = 0 ;
See as attachment the correct query plan for an other 'user'.
I confirm by executing manual VACUUM ANALYZE that the problem is solved.
But what i don't understand is that i would expect autovacuum to do the job.
Lionel
Kevin Grittner a écrit :
lionel duboeuf lionel.dubo...@boozter.com wrote:
Can you force 8.4 to generate the same plan as 8.1? For example by running
SET enable_hashjoin = off;
before you run EXPLAIN on the query? If so, then we can compare the
numbers from the forced plan with the old plan and maybe figure out why it
didn't use the same old plan in 8.4 as it did in
AI Rumman wrote:
explain analyze
select *
from vtiger_crmentity
inner JOIN vtiger_users
ON vtiger_users.id http://vtiger_users.id =
vtiger_crmentity.smownerid
where vtiger_crmentity.deleted = 0 ;
QUERY
PLAN
lionel duboeuf wrote:
Kevin Grittner a écrit :
I just reread your original email, and I'm not sure I understand
what you meant regarding VACUUM ANALYZE. If you run that right
beforehand, do you still get the slow plan for user 10?
I confirm by executing manual VACUUM ANALYZE that the
Reydan Cankur wrote:
I want to spread out the workload on all cores. But also I want to
set the core number; for example first I want to spread out the
workload to 32 cores then 64 cores and see the scalability.
PostgreSQL itself won't use more cores than you have active
connections, so
Scott Marlowe scott.marl...@gmail.com writes:
On Mon, Feb 15, 2010 at 2:35 AM, AI Rumman rumman...@gmail.com wrote:
Please have a look at the following explain plan:
Hash Join (cost=3665.17..40019.25 rows=640439 width=1603) (actual
time=115.613..3288.436 rows=638081 loops=1)
Hash Cond:
Ben Chobot wrote:
Here is the plan on 8.4.2:
Here is the very much less compact plan for the same query on
8.1.19:
Could you show the query, along with table definitions (including
indexes)?
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make
On Feb 15, 2010, at 7:59 AM, Kevin Grittner wrote:
Could you show the query, along with table definitions (including
indexes)?
Oh, yeah, I suppose that would help. :)
http://wood.silentmedia.com/bench/query_and_definitions
(I'd paste them here for posterity but I speculate the reason my
On Sat, Feb 13, 2010 at 2:58 AM, Bryce Nesbitt bry...@obviously.com wrote:
So as the op, back to the original posting
In the real world, what should I do? Does it make sense to pull the AND
articles.indexed clause into an outer query? Will that query simply
perform poorly on other
On Mon, Feb 15, 2010 at 2:52 AM, lionel duboeuf
lionel.dubo...@boozter.com wrote:
See as attachment the correct query plan for an other 'user'.
I confirm by executing manual VACUUM ANALYZE that the problem is solved.
But what i don't understand is that i would expect autovacuum to do the job.
Ben Chobot be...@silentmedia.com writes:
On Feb 15, 2010, at 7:59 AM, Kevin Grittner wrote:
Could you show the query, along with table definitions (including
indexes)?
Oh, yeah, I suppose that would help. :)
http://wood.silentmedia.com/bench/query_and_definitions
It looks like the problem
Awesome, that did the trick. Thanks Tom! So I understand better, why is my case
not the normal, better case?
(I assume the long-term fix is post-9.0, right?)
On Feb 15, 2010, at 9:26 AM, Tom Lane wrote:
Ben Chobot be...@silentmedia.com writes:
On Feb 15, 2010, at 7:59 AM, Kevin Grittner
Good day,
I have a PostgreSQL 8.4 database installed on WinXP x64 with very heavy
writing and updating on a partitioned table. Sometimes within one minute,
there are tens of file with size=1,048,576kb (such as
filenode.1,filenode.2,...filenode.43) created in the database subdirectory
within
Good day!
We bought a new WinXP x64 Professional, it has 12GB memory.
I installed postgresql-8.4.1-1-windows version on this PC, also installed
another .Net application which reads in data from a TCP port and
insert/update the database, the data volume is large, with heavy writing and
updating
On Feb 15, 2010, at 11:59 AM, Rose Zhou wrote:
Good day,
I have a PostgreSQL 8.4 database installed on WinXP x64 with very heavy
writing and updating on a partitioned table. Sometimes within one minute,
there are tens of file with size=1,048,576kb (such as
Thanks Ben:
I will adjust the auto vacuum parameters. It is on now, maybe not frequently
enough.
How to get the disk space back to OS? Will a Vacuum Full Verbose get the
disk space back to OS?
Best Regards
Rose Zhou
_
From: Ben Chobot [mailto:be...@silentmedia.com]
Sent:
On Mon, 2010-02-15 at 14:59 -0500, Rose Zhou wrote:
Good day,
I have a PostgreSQL 8.4 database installed on WinXP x64 with very heavy
writing and updating on a partitioned table. Sometimes within one minute,
there are tens of file with size=1,048,576kb (such as
19 matches
Mail list logo
