From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | André Volpato <andre(dot)volpato(at)ecomtecnologia(dot)com(dot)br> |
Cc: | "PostgreSQL" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Hash join in 8.3 |
Date: | 2007-12-13 21:24:40 |
Message-ID: | 87hcimnv8n.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
André Volpato <andre(dot)volpato(at)ecomtecnologia(dot)com(dot)br> writes:
> Gregory Stark escreveu:
>> André Volpato <andre(dot)volpato(at)ecomtecnologia(dot)com(dot)br> writes:
>>
>> I think the answer is that if you have bad statistics you'll get a bad plan
>> and which bad plan is going to be pretty much random.
>>
> I believe the statistics are ok, I´ve runned vacuum analyze before all those
> tries.
Sorry, I should have said "bad estimates". That is, because of the
j*1.5 BETWEEN 3000000 AND 4000000
clause the optimizer isn't going to be able to come up with a good estimate of
how many rows that will match. What plan it picks when it has such a bad
estimate is going to be pretty random, dependant on just what plans would be
good in a situation entirely unrelated to the reality.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
From | Date | Subject | |
---|---|---|---|
Next Message | André Volpato | 2007-12-13 21:29:38 | Re: Hash join in 8.3 |
Previous Message | Simon Riggs | 2007-12-13 21:15:55 | Re: [GENERAL] Slow PITR restore |