From: | Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: progress report for ANALYZE |
Date: | 2019-08-14 07:28:32 |
Message-ID: | CAPmGK15VkpMALmhOF9QEm=DS_AQmj36V26ZZQbzBo5_p8igG8w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Tue, Aug 13, 2019 at 11:01 PM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> On the subject of FDW support: I did look into supporting that before
> submitting this. I think it's not academically difficult: just have the
> FDW's acquire_sample_rows callback invoke the update_param functions
> once in a while. Sadly, in practical terms it looks like postgres_fdw
> is quite stupid about ANALYZE (it scans the whole table??) so doing
> something that's actually useful may not be so easy. At least, we know
> the total relation size and maybe we can add the ctid column to the
> cursor in postgresAcquireSampleRowsFunc so that we have a current block
> number to report (becing careful about synchronized seqscans).
I don't follow this thread fully, so I might miss something, but I
don't think that's fully applicable, because foreign tables managed by
postgres_fdw can be eg, views on the remote side.
> I do wonder why doesn't postgres_fdw use TABLESAMPLE.
Yeah, that's really what I'm thinking for PG13; but I think we would
still need to scan the whole table in some cases (eg, when the foreign
table is a view on the remote side), because the TABLESAMLE clause can
only be applied to regular tables and materialized views.
> I did not look at other FDWs at all, mind.
IIUC, oracle_fdw already uses the SAMPLE BLOCK clause for that. Right?
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2019-08-14 08:41:15 | Re: use of the term "verifier" with SCRAM |
Previous Message | David Rowley | 2019-08-14 07:25:10 | Re: Speed up transaction completion faster after many relations are accessed in a transaction |