Message-ID: <cd3f2fda-d4cc-4371-210f-fc339d53b885@enterprisedb.com>
Date: Wed, 21 Dec 2022 13:08:08 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.1
Subject: Re: postgres_fdw: using TABLESAMPLE to collect remote sample
To: Tom Lane <tgl@sss.pgh.pa.us>, James Finnerty <jfinnert@amazon.com>
Cc: pgsql-hackers@lists.postgresql.org,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>
References: <151e835f-55d6-ddbc-b5b4-07ee606aba44@enterprisedb.com>
 <03182011-10a4-97b4-7c70-d99aa1c11eed@enterprisedb.com>
 <167112207543.1120.12195641719862911275.pgcf@coridan.postgresql.org>
 <3377008.1671122816@sss.pgh.pa.us>
Content-Language: en-US
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
In-Reply-To: <3377008.1671122816@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/cd3f2fda-d4cc-4371-210f-fc339d53b885%40enterprisedb.com>
Precedence: bulk

On 12/15/22 17:46, Tom Lane wrote:
> James Finnerty <jfinnert@amazon.com> writes:
>> This patch looks good to me.  I have two very minor nits: The inflation
>> of the sample size by 10% is arbitrary but it doesn't seem unreasonable
>> or concerning.  It just makes me curious if there are any known cases
>> that motivated adding this logic.
> 
> I wondered why, too.
> 

Not sure about known cases, but the motivation is explained in the
comment before the 10% is applied.

The repluples value is never going to be spot on, and we use that to
determine what fraction of the table to sample (because all built-in
TABLESAMPLE methods only accept fraction to sample, not expected number
of rows).

If pg_class.reltuples is lower (than the actual row count), we'll end up
with sample fraction too high. That's mostly harmless, as we'll then
discard some of the rows locally.

But if the pg_class.reltuples is higher, we'll end up sampling too few
rows (less than targrows). This can happen e.g. after a bulk delete.

Yes, the 10% value is mostly arbitrary, and maybe it's pointless. How
much may the stats change with 10% larger sample? Probably not much, so
is it really solving anything?

Also, maybe it's fixing the issue at the wrong level - if stale
reltuples are an issue, maybe the right fix is making it more accurate
on the source instance. Decrease autovacuum_vacuum_scale_factor, or
maybe also look at pg_stat_all_tables or something.

regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company