Re: postgres_fdw: using TABLESAMPLE to collect remote sample - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: postgres_fdw: using TABLESAMPLE to collect remote sample
Date
Msg-id 233ee0b3-4da0-3370-cd0b-1b8528851ddd@enterprisedb.com
Whole thread Raw
In response to Re: postgres_fdw: using TABLESAMPLE to collect remote sample  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: postgres_fdw: using TABLESAMPLE to collect remote sample  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 12/31/22 05:42, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@enterprisedb.com> writes:
>> After thinking about it a bit more I decided to rip out the 10% sampling
>> rate inflation.
> 
> +1.  I'm not sure if there's anything more we need to do there, but
> that didn't seem like that was it.
> 
> I notice that the committed patch still has a reference to that hack
> though:
> 
> +            * Ensure the sampling rate is between 0.0 and 1.0, even after the
> +            * 10% adjustment above.  (Clamping to 0.0 is just paranoia.)
> 
> Clamping still seems like a wise idea, but the comment is just
> confusing now.
> 

Yeah, I missed that reference. Will fix.

> Also, I wonder if there is any possibility of ANALYZE failing
> with
> 
> ERROR:  TABLESAMPLE clause can only be applied to tables and materialized views
> 
> I think the patch avoids that, but only accidentally, because
> reltuples will be 0 or -1 for a view.  Maybe it'd be a good
> idea to pull back relkind along with reltuples, and check
> that too?

Not sure. I guess we can rely on reltuples being 0 or -1 in such cases,
but maybe it'd be good to at least mention that in a comment? We're not
going to use other reltuples values for views etc.


regards

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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: split TOAST support out of postgres.h
Next
From: Peter Eisentraut
Date:
Subject: Re: Transparent column encryption