Re: use of SPI by postgresImportForeignStatistics

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.

In response to

Browse pgsql-hackers by date

  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