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

From: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(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 14:51:39
Message-ID: CALt0+o9iEc+zNZLk3DB_O2+pvrisSwipvRwPJb6kwnq0TV9DqA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

(cough cough, missed the Reply to all button)

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 remember having seen something I could use for
selectivity (such as the n_distinct stuff). It's not that big a deal
if it's a little worth elsewhere as there are far less places so the
effects of a bad plan are more contained.

--
Guillaume

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Guillaume Lelarge 2012-12-08 15:15:42 Re: Slow query: bitmap scan troubles
Previous Message Tom Lane 2012-12-08 04:16:45 Re: Any idea on how to improve the statistics estimates for this plan?