On Sat, Dec 8, 2012 at 5:19 AM, Guillaume Smet <guillaume.smet@xxxxxxxxx> wrote: > Hi Jeff, > > On Sat, Dec 8, 2012 at 3:32 AM, Jeff Janes <jeff.janes@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
