Re: Row estimates off by two orders of magnitude with hstore - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Row estimates off by two orders of magnitude with hstore
Date
Msg-id CAHyXU0y4+c6-EoeHzVH1zQeyfq+CWo9zOKcJCrRZ_G2xiysOjQ@mail.gmail.com
Whole thread Raw
In response to Re: Row estimates off by two orders of magnitude with hstore  (Patrick Krecker <patrick@judicata.com>)
Responses Re: Row estimates off by two orders of magnitude with hstore  (Patrick Krecker <patrick@judicata.com>)
List 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 by date:

Previous
From: Patrick Krecker
Date:
Subject: Re: Row estimates off by two orders of magnitude with hstore
Next
From: Patrick Krecker
Date:
Subject: Re: Row estimates off by two orders of magnitude with hstore