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.
regards, tom lane
