Do you use PostGIS BRIN?

[Regina Obe]

> On 1/5/25 08:53, Regina Obe wrote:
>> We are thinking of removing BRIN support in PostGIS because it has a serious
>> bug as discussed here.
>> 
>> https://lists.osgeo.org/pipermail/postgis-devel/2025-January/030457.html
>> 
>> and here - https://trac.osgeo.org/postgis/ticket/5564
>> 
>> that currently causes crashes during Index building.
>> 
>> The two options on the table are:
>> 
>> 1) Fix the issue
>> 2) Remove BRIN Support
>> 
>> 
>> I'm leaning toward the removal of BRIN support because I see no point
>> carrying the technical baggage of continuously supporting BRIN and testing
>> it 
>> if very very few people are using it.  Yes this will be a breaking change
>> for those that use it.
>> 

> I'm not really involved in PostGIS and I'm not sure how widely used the
> BRIN opclasses are, but I'd be willing to help with fixing/testing them.
> I find BRIN indexes to be quite neat, it'd be somewhat sad if one of the
> main projects built on Postgres ditched them.

>From discussions with some folks, it is more widely used than I had expected.
But the two uses I have heard from so far are one-offs for having a lightweight and relatively fast to build
Index for openstreetmap data and the like, which as much as I can guess is then thrown away after data is completely loaded.

> I haven't tried but my impression is the fix wouldn't be that hard. Ofc,
> that doesn't take away the long-term maintenance cost, but AFAIK this
> shouldn't break very often either.
> regards

> -- 
> Tomas Vondra

The annoyance I have is several people have said it should be easy to fix, but no one has stepped up to the plate
to put their time where their mouth is.  But if you are willing to put in the time, that pushes us closer in the  "Keeping" direction.

The other issue I have is with the upgrade issues we'll run into.  Based on my understanding, we'd need to modify the opclasses
and introduce more functions.  This is feels kind of dirty back-porting such a change - adding functions to "Stable" versions of PostGIS.
I think we've done that once before.

My idea of removing it wasn't to remove it so much as neuter it for the stable versions.
By that I mean changing one of the backend functions, so it just errors out on index building etc so we don't need to touch the SQL API at all
And anyone running with just the libs that forgot to do the  SELECT postgis_extensions_upgrade();  would be safe from accidentally crashing.

I haven't walked thru if that is even doable, but my thought was at least we wouldn't be introducing new functions in stable versions of PostGIS
We'd just be changing the behavior to not do harmful things.

Then later on we could decide to fix it, only fix it for PostGIS 3.6, or just remove the entrails of BRIN for 3.6 and above.