Re: [PGSQL v8.2.5] Similar queries behave differently - Mailing list pgsql-general

From Gregory Stark
Subject Re: [PGSQL v8.2.5] Similar queries behave differently
Date
Msg-id 87lk9rl9tj.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: [PGSQL v8.2.5] Similar queries behave differently  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: [PGSQL v8.2.5] Similar queries behave differently  (Reg Me Please <regmeplease@gmail.com>)
List pgsql-general
"Gregory Stark" <stark@enterprisedb.com> writes:

> "Reg Me Please" <regmeplease@gmail.com> writes:
>
>>                ->  Seq Scan on tt_elem  (cost=0.00..29.40 rows=1940 width=8)
>>                                         (actual time=0.012..0.013 rows=1 loops=1)
>
> The discrepancy etween the estimated rows and actual rows makes me think
> you've not analyzed this table in a long time. It's probably best to analyze
> the whole database to have a consistent set of statistics and to catch any
> other old table stats.
>
> There could be other misestimations based due to Postgres limitations but
> first fix the out of date stats and re-post both plans.

Actually it's pretty clear there are some other bad estimations as well. You
should send along the view definition too.

And I would recommend you try it with a normal JOIN ON/USING instead of the
NATURAL JOIN. It's possible it's joining on some unexpected columns -- though
that doesn't really look like it's the case here.

--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

pgsql-general by date:

Previous
From: "Peter Childs"
Date:
Subject: Re: conditional alter table add ?
Next
From: Gregory Stark
Date:
Subject: Re: select count() out of memory