From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | James Finnerty <jfinnert(at)amazon(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: postgres_fdw: using TABLESAMPLE to collect remote sample |
Date: | 2022-12-31 14:16:38 |
Message-ID: | 233ee0b3-4da0-3370-cd0b-1b8528851ddd@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/31/22 05:42, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-12-31 14:17:25 | Re: Transparent column encryption |
Previous Message | Andrew Dunstan | 2022-12-31 13:48:15 | Re: split TOAST support out of postgres.h |