Re: query planner not using the correct index - Mailing list pgsql-performance

From Joshua Shanks
Subject Re: query planner not using the correct index
Date
Msg-id 84f0acdb0808071604j73992accp1f770c4c7deec5d9@mail.gmail.com
Whole thread Raw
In response to Re: query planner not using the correct index  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-performance
On Thu, Aug 7, 2008 at 5:38 PM, Gregory Stark <stark@enterprisedb.com> wrote:
> Measuring n_distinct from a sample is inherently difficult and unreliable.
> When 98% of your table falls into those categories it's leaving very few
> chances for the sample to find many other distinct values.
>
> I haven't seen the whole thread, if you haven't tried already you could try
> raising the statistics target for these columns -- that's usually necessary
> anyways when you have a very skewed distribution like this.
>

I did some tweaking on default_statistics_target earlier in the thread
with no luck. I just retried it with default_statistics_target set to
500 and did the VACUUM ANALYZE on the other table this time and
started to see better results and more of the behavior I would expect.

Is there a way to set the stats target for just one column? That seems
like what we might need to do.

> Yeah, Heikki's suggested having a kind of "branch" plan node that knows how
> where the break-point is between two plans and can call the appropriate one.
> We don't have anything like that yet.
>

Is this already on a todo list or is there a bug for it?

pgsql-performance by date:

Previous
From: Gregory Stark
Date:
Subject: Re: query planner not using the correct index
Next
From: Tom Lane
Date:
Subject: Re: query planner not using the correct index