| 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: | Whole Thread | Raw Message | 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 |