MIME-Version: 1.0
References: 
 <CA+TgmoYqMtWb4zLUkT98oFnEkJ=Wz0Pw-ggDJrp9wnSXPzUaeQ@mail.gmail.com>
 <CAPmGK161TJ4G01eptv3sBqgxa4SNHDE9VRqoC6jy5Y6G3D8yDw@mail.gmail.com>
 <CA+TgmoZpwfTGqqp=0efV99e_BMYWdLFq2XKRWVSDcukifkZMeA@mail.gmail.com>
 <CADkLM=dxe8NbQu4RNi2OFXpaRKdpS0-CHGm6Mqtf_rW155BM4g@mail.gmail.com>
 <CADkLM=cV=uezAKyZdyyxnZOBRhGLUSbeYfDj5_jbDCLP9LP24Q@mail.gmail.com>
 <CA+TgmoaVcgZJpwxyi7HEfNMJhmm7BXkTQ468jvxkW2QzQZRkvg@mail.gmail.com>
 <CADkLM=dy18dDJ+j3-_Ofn11vt5J7zF33oTWnE6N=ePc83uS91A@mail.gmail.com>
 <CA+TgmobLcuO+6gSLftG8gQFBZx1DyVt88JZ4--292FQJkKDs4A@mail.gmail.com>
In-Reply-To: 
 <CA+TgmobLcuO+6gSLftG8gQFBZx1DyVt88JZ4--292FQJkKDs4A@mail.gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
Date: Wed, 17 Jun 2026 12:03:33 -0400
Message-ID: 
 <CADkLM=cVEj1mCfRWsXcHJF06jdd-oWioNtkL0E7B+uqMxZ_aFw@mail.gmail.com>
Subject: Re: use of SPI by postgresImportForeignStatistics
To: Robert Haas <robertmhaas@gmail.com>
Cc: Etsuro Fujita <etsuro.fujita@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000005316d006547534d8"
Archived-At: 
 <https://www.postgresql.org/message-id/CADkLM%3DcVEj1mCfRWsXcHJF06jdd-oWioNtkL0E7B%2BuqMxZ_aFw%40mail.gmail.com>
Precedence: bulk

--0000000000005316d006547534d8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 16, 2026 at 6:57=E2=80=AFPM Robert Haas <robertmhaas@gmail.com>=
 wrote:

> On Tue, Jun 16, 2026 at 6:50=E2=80=AFPM Corey Huinker <corey.huinker@gmai=
l.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.

--0000000000005316d006547534d8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, Jun 16, 2026 at 6:57=E2=80=AFPM Rober=
t Haas &lt;<a href=3D"mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On=
 Tue, Jun 16, 2026 at 6:50=E2=80=AFPM Corey Huinker &lt;<a href=3D"mailto:c=
orey.huinker@gmail.com" target=3D"_blank">corey.huinker@gmail.com</a>&gt; w=
rote:<br>
&gt; 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.<br>
<br>
Whatever ends up in core can (indeed must) be reused by every FDW. So<br>
making things simpler for the FDW and more complex for core seems<br>
likely to be the right tradeoff in general.</blockquote><div><br></div><div=
>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 functi=
ons land in the header files. It&#39;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 s=
pecific to FDWs. Personally, I think FDWs will be 90-95% of the usages outs=
ide of the existing SQL-defined functions, but 95% is not 100%, so I&#39;d =
be inclined to leave them in a statistics/stats utils header.</div></div></=
div>

--0000000000005316d006547534d8--