RE: Support for VACUUMing Foreign Tables
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: Support for VACUUMing Foreign Tables |
Дата | |
Msg-id | TYAPR01MB2990552A312E1C4F651F0B89FE509@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Support for VACUUMing Foreign Tables (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Support for VACUUMing Foreign Tables
Re: Support for VACUUMing Foreign Tables Re: Support for VACUUMing Foreign Tables |
Список | 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 по дате отправления: