Re: Row estimates off by two orders of magnitude with hstore
От | Merlin Moncure |
---|---|
Тема | Re: Row estimates off by two orders of magnitude with hstore |
Дата | |
Msg-id | CAHyXU0y4+c6-EoeHzVH1zQeyfq+CWo9zOKcJCrRZ_G2xiysOjQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Row estimates off by two orders of magnitude with hstore (Patrick Krecker <patrick@judicata.com>) |
Ответы |
Re: Row estimates off by two orders of magnitude with hstore
|
Список | pgsql-performance |
On Wed, Jun 10, 2015 at 3:55 PM, Patrick Krecker <patrick@judicata.com> wrote: > OK. Well, fortunately for us, we have a lot of possible solutions this > problem, and it sounds like actually getting statistics for attributes > ? 'reference' is not realistic. I just wanted to make sure it wasn't > some configuration error on our part. > > Can anyone explain where exactly the estimate for that clause comes from? > > I tried adding an index and I don't think it improved the estimation, > the planner still thinks there will be 9k rows as a result of type_id > = 23 and attributes ? 'reference'. [1]. It might make the pathological > plan less likely though. It's not clear to me that it reduces the risk > of a pathological plan to zero. no, but done in conjunction with disabling managing out nestloops and materliaze query plans, nestloops (say, via SET LOCAL) it will probably be fast and future proof.. merlin
В списке pgsql-performance по дате отправления: