From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
cc: Andres Freund <andres@anarazel.de>,
        Fujii Masao <masao.fujii@oss.nttdata.com>,
        Robert Haas <robertmhaas@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: postgres_fdw: using TABLESAMPLE to collect remote sample
In-reply-to: <4e1c9731-8f8a-8b3e-17b8-d4c81b70df70@enterprisedb.com>
References: <151e835f-55d6-ddbc-b5b4-07ee606aba44@enterprisedb.com>
 <2080021.1644601183@sss.pgh.pa.us>
 <CA+TgmoYx596-mqUP=xf0DdQ97UERxXfzhR0Otpa411sGV1vKow@mail.gmail.com>
 <2082308.1644602761@sss.pgh.pa.us>
 <CA+TgmobqyX6s2VQ0=HGZc4xW+tOusPa0FLfSevH_PA2Kum34BA@mail.gmail.com>
 <60c4dc7c-82e8-ab04-a938-d7b7c5ee75f0@enterprisedb.com>
 <84afe85f-2aa0-5aef-fa4a-59759afc03fb@enterprisedb.com>
 <ac2fb459-3def-6a7c-afce-46ebe5f66575@oss.nttdata.com>
 <76202fae-0c34-4f49-e3a0-1071c3fcf9e1@enterprisedb.com>
 <2d679fff-fb74-8ad1-fe57-094563f2aa55@enterprisedb.com>
 <20220322011820.vlz3l577elz46wln@alap3.anarazel.de>
 <3998908.1658008664@sss.pgh.pa.us>
 <113b8f5b-eec6-ea60-8508-439f2692887c@enterprisedb.com>
 <782558.1658169910@sss.pgh.pa.us>
 <4e1c9731-8f8a-8b3e-17b8-d4c81b70df70@enterprisedb.com>
Comments: In-reply-to Tomas Vondra <tomas.vondra@enterprisedb.com>
	message dated "Tue, 19 Jul 2022 21:07:08 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1296999.1658258876.1@sss.pgh.pa.us>
Date: Tue, 19 Jul 2022 15:27:56 -0400
Message-ID: <1297000.1658258876@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1297000.1658258876%40sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
> I we want to improve sampling for partitioned cases (where the foreign
> table is just one of many partitions), I think we'd have to rework how
> we determine sample size for each partition. Now we simply calculate
> that from relpages, which seems quite fragile (different amounts of
> bloat, different tuple densities) and somewhat strange for FDW serves
> that don't use the same "page" concept.

> So it may easily happen we determine bogus sample sizes for each
> partition. The difficulties when calculating the sample_frac is just a
> secondary issue.

> OTOH the concept of a "row" seems way more general, so perhaps
> acquire_inherited_sample_rows should use reltuples, and if we want to do
> correction it should happen at this stage already.

Yeah, there's definitely something to be said for changing that to be
based on rowcount estimates instead of physical size.  I think it's
a matter for a different patch though, and not a reason to hold up
this one.

			regards, tom lane