RE: Support for VACUUMing Foreign Tables - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: Support for VACUUMing Foreign Tables
Date
Msg-id TYAPR01MB2990552A312E1C4F651F0B89FE509@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Support for VACUUMing Foreign Tables  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Support for VACUUMing Foreign Tables
Re: Support for VACUUMing Foreign Tables
Re: Support for VACUUMing Foreign Tables
List pgsql-hackers
From: Bharath Rupireddy <bharath.rupireddyforpostgres@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
processingas alternative to DELETE, I think VACUUM is purely the data storage maintenance that's performed by the DBA
andcan be done naturally locally on the server where the table resides.  (The existing ANALYZE on FDW is an exception;
it'suseful 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
functionsthat 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
willbe 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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Testing autovacuum wraparound (including failsafe)
Next
From: David Rowley
Date:
Subject: Re: What is lurking in the shadows?