Here is my log analysis:
Due to a database recovery task it appears that:
I stopped postgresql
I started postgresql (and as default autovacuum daemon)
I restored the databases (need to restore 4 databases)
It seems that after database 1 have been restored, autovacumm
started on it
Here is my log analysis:
Due to a database recovery task it appears that:
I stopped postgresql
I started postgresql (and as default autovacuum daemon)
I restored the databases (need to restore 4 databases)
It seems that after database 1 have been restored, autovacumm
started on it
I am getting seq_scan on vtiger_account. Index is not using.
Could anyone please tell me what the reason is?
explain analyze
select *
from vtiger_account
LEFT JOIN vtiger_account vtiger_account2
ON vtiger_account.parentid = vtiger_account2.accountid
A mistake on the previous mail.
explain analyze
select *
from vtiger_account
LEFT JOIN vtiger_account vtiger_account2
ON vtiger_account.parentid = vtiger_account2.accountid
QUERY
PLAN
lionel duboeuf wrote:
I stopped postgresql
I started postgresql (and as default autovacuum daemon)
I restored the databases (need to restore 4 databases)
It seems that after database 1 have been restored, autovacumm
started on it and has been stopped while restoring database 2.
Does
Greg Smith wrote:
I've been full-on vocally anti-Dell ever since they started releasing
PCs with the non-standard ATX power supply pinout; that was my final
straw with their terrible quality decisions.
Yep, makes me feel validated for all of the anti-Dell advice I have
given over the years
AI Rumman rumman...@gmail.com wrote:
Merge Left Join (cost=0.00..1383629.28 rows=231572 width=264)
(actual time=0.166..1924.417 rows=231572 loops=1)
Merge Cond: (outer.parentid = inner.accountid)
- Index Scan using vtiger_account_parentid_idx on
vtiger_account (cost=0.00..642475.34
Thank you Kevin and Scott for all the explanations. ;-)
regards
Lionel
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
lionel duboeuf a écrit :
Thank you Kevin and Scott for all the explanations. ;-)
regards
Lionel
Sorry for forgetting Jorge also.
regards.
All this ,encourage me to know more about database management.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make
I'm having problems with another one of my queries after moving from 8.1.19 to
8.4.2. On 8.1.19, the plan looked like this:
http://wood.silentmedia.com/bench/8119
That runs pretty well. On 8.4.2, the same query looks like this:
http://wood.silentmedia.com/bench/842_bad
If I turn off mergejoin
On Mon, 2010-02-08 at 09:49 -0800, Josh Berkus wrote:
FWIW, back when deadline was first introduced Mark Wong did some tests
and found Deadline to be the fastest of 4 on DBT2 ... but only by about
5%. If the read vs. checkpoint analysis is correct, what was happening
is the penalty for
On Feb 16, 2010, at 1:29 PM, Ben Chobot wrote:
I'm having problems with another one of my queries after moving from 8.1.19
to 8.4.2. On 8.1.19, the plan looked like this:
http://wood.silentmedia.com/bench/8119
That runs pretty well. On 8.4.2, the same query looks like this:
Ben Chobot be...@silentmedia.com writes:
Awesome, that did the trick. Thanks Tom! So I understand better, why is my
case not the normal, better case?
Well, the short answer is that the 8.4 changes here are in the nature of
two steps forward and one step back. The long-term goal is to increase
13 matches
Mail list logo
