Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1
От | Tom Lane |
---|---|
Тема | Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1 |
Дата | |
Msg-id | 11894.1368477199@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: RT3.4 query needed a lot more tuning with 9.2 than it did with 8.1 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: RT3.4 query needed a lot more tuning with 9.2 than it
did with 8.1
|
Список | pgsql-performance |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, May 13, 2013 at 4:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> You know, of course, that the join size estimate isn't arrived at that >> way. Still, this point does make it seem more like a planner bug and >> less like bad input stats. It would be nice to see a self-contained >> example ... > Yeah, I remember there have been examples like this that have come up > before. Unfortunately, I haven't fully grokked what's actually going > on here that allows this kind of thing to happen. Refresh my memory > on where the relevant code is? The point is that we estimate the size of a joinrel independently of any particular input paths for it, and indeed before we've built any such paths. So this seems like a bug somewhere in selectivity estimation, but I'm not prepared to speculate as to just where. regards, tom lane
В списке pgsql-performance по дате отправления: