Re: Hypothetical indexes using BRIN broken since pg10
От | Julien Rouhaud |
---|---|
Тема | Re: Hypothetical indexes using BRIN broken since pg10 |
Дата | |
Msg-id | CAOBaU_Yk+JCFuGWzrnxDVb4dOysTn=DnZCyyrdV76y-NmBBdyA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hypothetical indexes using BRIN broken since pg10 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Hypothetical indexes using BRIN broken since pg10
|
Список | 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 по дате отправления: