From: Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com>
> I think it will be useful to allow foreign tables to be VACUUMed if
> the underlying FDW supports, currently VACUUM doesn't support foreign
> tables, see [1].
Could you let us imagine more concretely how useful it will be? While TRUNCATE
can be part of an application's data processing as alternative to DELETE, I
think VACUUM is purely the data storage maintenance that's performed by the DBA
and can be done naturally locally on the server where the table resides. (The
existing ANALYZE on FDW is an exception; it's useful to also have data
statistics locally.)
> this may not be much useful for FDWs that connect to remote non-MVCC
> databases where the concept of VACUUM may not apply, but for
> postgres_fdw and others it might help.
Can you show some examples of "others"? I believe we should be careful not to
make the FDW interface a swamp for functions that are only convenient for
PostgreSQL.
How about adding a routine to the FDW interface that allows to execute an
arbitrary command like the following? VACUUM will be able to use this.
PGresult *DoCommandPathThrough(ForeignTable *table, const char *command);
Or, maybe it's more flexible to use ForeignServer instead of ForeignTable.
Regards
Takayuki Tsunakawa
