| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: use of SPI by postgresImportForeignStatistics |
| Date: | 2026-06-17 16:03:33 |
| Message-ID: | CADkLM=cVEj1mCfRWsXcHJF06jdd-oWioNtkL0E7B+uqMxZ_aFw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jun 16, 2026 at 6:57 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Jun 16, 2026 at 6:50 PM Corey Huinker <corey(dot)huinker(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-06-17 16:18:14 | Re: [PATCH] Improving index selection for logical replication apply with replica identity full |
| Previous Message | Jacob Champion | 2026-06-17 16:01:28 | Re: Direction for test frameworks: Perl TAP vs. Python/pytest |