Re: progress report for ANALYZE
Etsuro Fujita <etsuro.fujita@gmail.com>
From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp>, Pg Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-08-14T07:28:32Z
Lists: pgsql-hackers
Hi, On Tue, Aug 13, 2019 at 11:01 PM Alvaro Herrera <alvherre@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
Commits
-
Doc: Fix and tweak documentation for ANALYZE reporting
- 5ba40b62318e 13.0 landed