Re: Performance Killer 'IN' ? - Mailing list pgsql-general

From Kai Hessing
Subject Re: Performance Killer 'IN' ?
Date
Msg-id 49d5qgFnuic1U1@individual.net
Whole thread Raw
In response to Re: Performance Killer 'IN' ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Performance Killer 'IN' ?  (Kai Hessing <kai.hessing@hobsons.de>)
List pgsql-general
Tom Lane wrote:
> Well, here's our problem it would seem: the planner is estimating the IN
> clause to match 317227 rows, rather than the actual 2522.  That's
> naturally going to bias it against choosing an indexscan.  You need to
> get that estimate closer before there's going to be much chance of
> choosing the right plan.
>
>> What do you mean with larger statistics target?
>
> See ALTER TABLE SET STATISTICS, or just change default_statistics_target
> and re-ANALYZE.

Thanks, that definitly looks like a starting point. I will test it and
post my results. Btw. what happens if the estimation would be to low?

pgsql-general by date:

Previous
From: "Christopher Condit"
Date:
Subject: Re: pgsql and streams
Next
From: Emi Lu
Date:
Subject: Which error constant to use for "permission deny error when updating a table that user is not allowd to "