Re: Any idea on how to improve the statistics estimates for this plan?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Any idea on how to improve the statistics estimates for this plan?
Date: 2012-12-08 19:03:27
Message-ID: CAMkU=1w_CzLZE4tJhpP9DePMOooGkd7XBvZeCkMB-Y_os9NFig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sat, Dec 8, 2012 at 5:19 AM, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com> wrote:
> Hi Jeff,
>
> On Sat, Dec 8, 2012 at 3:32 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> If those estimates are better, it probably means that your filter
>> condition is picking a part of the "el JOIN l" that has much different
>> selectivity to r than the full set does, and PostgreSQL has no way of
>> knowing that.
>
> It's certainly that. The fact is that this query is OK on most of the
> French territory but it doesn't go well when you're looking at Paris
> area in particular. As the query is supposed to return the shows you
> can book, the selectivity is quite different as Paris has a lot of
> places AND places organize a lot more shows in Paris than in the rest
> of France. I was hoping that the high number of places would be enough
> to circumvent the second fact which is much harder for PostgreSQL to
> get but it looks like it's not.
>
> Is there any way I could mitigate this issue by playing with planner
> knobs?

I don't know the answer to that. But does it matter? If it knew you
were going to get 300,000 rows rather than 2, would it pick a better
plan?

Cheers,

Jeff

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jeff Janes 2012-12-10 03:53:45 Re: Why is PostgreSQL 9.2 slower than 9.1 in my tests?
Previous Message Guillaume Lelarge 2012-12-08 15:15:42 Re: Slow query: bitmap scan troubles