Re: use of SPI by postgresImportForeignStatistics - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: use of SPI by postgresImportForeignStatistics
Date
Msg-id CADkLM=cVEj1mCfRWsXcHJF06jdd-oWioNtkL0E7B+uqMxZ_aFw@mail.gmail.com
Whole thread
In response to Re: use of SPI by postgresImportForeignStatistics  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: use of SPI by postgresImportForeignStatistics
List pgsql-hackers
On Tue, Jun 16, 2026 at 6:57 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Jun 16, 2026 at 6:50 PM Corey Huinker <corey.huinker@gmail.com> wrote:
> postgres_fdw will get slimmer for not having SPI in it. relation_stats.c and attribute_stats.c will have some temporary bloat until things can be refactored.

Whatever ends up in core can (indeed must) be reused by every FDW. So
making things simpler for the FDW and more complex for core seems
likely to be the right tradeoff in general.

I had assumed we wanted a generic C API to these two functions, but if we want something that is specific to FDWs, that might change where the functions land in the header files. It's an easy change to make if we change our minds, but it would be good to know if we do or do not want something specific to FDWs. Personally, I think FDWs will be 90-95% of the usages outside of the existing SQL-defined functions, but 95% is not 100%, so I'd be inclined to leave them in a statistics/stats utils header.

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Direction for test frameworks: Perl TAP vs. Python/pytest
Next
From: Bharath Rupireddy
Date:
Subject: Re: [PATCH] Improving index selection for logical replication apply with replica identity full