Re: Hypothetical indexes using BRIN broken since pg10 - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Hypothetical indexes using BRIN broken since pg10
Date
Msg-id CAOBaU_Yk+JCFuGWzrnxDVb4dOysTn=DnZCyyrdV76y-NmBBdyA@mail.gmail.com
Whole thread Raw
In response to Re: Hypothetical indexes using BRIN broken since pg10  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Hypothetical indexes using BRIN broken since pg10
List pgsql-hackers
On Mon, Sep 9, 2019 at 5:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Alvaro Herrera from 2ndQuadrant <alvherre@alvh.no-ip.org> writes:
> > On 2019-Sep-02, Tom Lane wrote:
> >> 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?
>
> The API change I'm proposing is surely not back-patchable.
>
> Whether we should bother back-patching a less capable stopgap fix
> is unclear to me.  Yeah, it's a bug that an index adviser can't
> try a hypothetical BRIN index; but given that nobody noticed till
> now, it doesn't seem like there's much field demand for it.
> And I'm not sure that extension authors would want to deal with
> testing minor-release versions to see if the fix is in, so
> even if there were a back-patch, it might go unused.

FWIW I maintain such an extension and testing for minor release
version is definitely not a problem.



pgsql-hackers by date:

Previous
From: Victor Wagner
Date:
Subject: PostgreSQL12 and older versions of OpenSSL
Next
From: Benjie Gillam
Date:
Subject: Re: [PATCH] Sort policies and triggers by table name in pg_dump.