On 2019-Aug-14, Etsuro Fujita wrote: > 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.
Oh, hmm, well I guess that covers the tables and matviews then ... I'm not sure there's a good way to cover foreign tables that are views or other stuff. Maybe that'll have to do. But at least it covers more cases than none. > > 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. Sure. > > I did not look at other FDWs at all, mind. > > IIUC, oracle_fdw already uses the SAMPLE BLOCK clause for that. Right? Yeah, it does that, I checked precisely oracle_fdw this morning. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
