On 2019-Sep-02, Tom Lane wrote:
> Julien Rouhaud <rjuju123@gmail.com> writes:
> > On Fri, Jul 26, 2019 at 1:34 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> >> The patch assumes the default pages_per_range setting, but looking at
> >> the code at https://github.com/HypoPG/hypopg, the extension actually
> >> takes pages_per_range into account when it estimates the index size. I
> >> guess there's no easy way to pass the pages_per_range setting down to
> >> brincostestimate(). I'm not sure what we should do about that, but seems
> >> that just using BRIN_DEFAULT_PAGES_PER_RANGE here is not very accurate.
>
> > Yes, hypopg can use a custom pages_per_range as it intercepts it when
> > the hypothetical index is created. I didn't find any way to get that
> > information in brincostestimate(), especially for something that could
> > backpatched. I don't like it, but I don't see how to do better than
> > just using BRIN_DEFAULT_PAGES_PER_RANGE :(
>
> I can tell you what I think ought to happen, but making it happen might
> be more work than this patch should take on.
>
> The right answer IMO is basically for the brinGetStats call to go
> away from brincostestimate and instead happen during plancat.c's
> building of the IndexOptInfo. In the case of a hypothetical index,
> it'd fall to the get_relation_info_hook to fill in suitable fake
> data.
So I'm not clear on what the suggested strategy is, here. Do we want
that design change to occur in the bugfix that would be backpatched, or
do we want the backbranches to use the patch as posted and then we apply
the above design on master only?
If the former -- is Julien interested in trying to develop that?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services