Hi, On Tue, Aug 13, 2019 at 11:01 PM Alvaro Herrera <alvhe...@2ndquadrant.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
