Re: Hypothetical indexes using BRIN broken since pg10

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera from 2ndQuadrant <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Hypothetical indexes using BRIN broken since pg10
Date: 2019-09-09 15:03:18
Message-ID: 18044.1568041398@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera from 2ndQuadrant <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message gc_11 2019-09-09 15:07:25 Does PostgreSQL support debian Linux on Arm CPU Platform?
Previous Message Dave Cramer 2019-09-09 14:58:02 pg_upgrade issues