Ben Chobot 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
the planner's abili
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:
>
> htt
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 che
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
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
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
AI Rumman 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 rows=2315
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
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.
> Doe
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
--
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
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 an
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 an
13 matches
Mail list logo
