Re: Poor Performance on Postgres 8.0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pallav Kalva <pkalva(at)deg(dot)cc>
Cc: PERFORM <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Poor Performance on Postgres 8.0
Date: 2005-01-28 21:34:24
Message-ID: 26388.1106948064@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Pallav Kalva <pkalva(at)deg(dot)cc> writes:
> On 8
> common | attribute | fknamestringid | 0 | 4
> | 80 | {2524,2434,2530,2522,2525,2523,2527,2526,2574,2531} |
> {0.219333,0.199333,0.076,0.0643333,0.0616667,0.05,0.0453333,0.042,0.04,0.0286667}
> | {2437,2528,2529,2538,2539,2540,2554,2562,2575,2584,2637} | 0.0274016

Given those stats, the planner is going to estimate that about 1/80th of
the attribute table matches any particular fknamestringid, and that's
what's driving it away from using the indexscan. I cannot tell whether
there are indeed a couple of thousand rows joining to the 'squareFeet'
string row (in which case the condition numericValue='775.0' must be
really selective) or whether this is an outlier case that joins to just
a few attribute rows.

The slightly different stats values for 7.4 would have given it a
slightly lower value for the cost of an indexscan by
idx_attribute_fknamestringid, but certainly not as low as your original
message shows. Perhaps you have some difference in parameter settings
in your 7.4 installation --- most likely a lower random_page_cost.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Pallav Kalva 2005-01-28 21:57:32 Re: Poor Performance on Postgres 8.0
Previous Message Pallav Kalva 2005-01-28 20:58:19 Re: Poor Performance on Postgres 8.0