> >> >> > I don't deal with Hot Standby's in my day-to-day but if you DROP SCHEMA > all of the spaced consumed by indexes and tables in that schema will be > freed. The vacuum might make a small difference in performance on the > system catalogs (pg_class, stats, etc) that were updated but with respect > to the dropped schema there won't be anything present there for vacuum to > touch. > > Create and populate a dummy table in a test setup, measure the HD space > taken in PGDATA, then drop it and measure again to see it in action. > > I've only done this using "TRUNCATE" - I've got a system with space > constraints a the same kind of "file data" table and freed up around 20GB > with a single fast truncate (though ensuring FKs wouldn't be a problem was > fun...). > > David J. > > Have made some tests just by doing:
1 - Creating a master server 2 - Creating a slave server 3 - Creating a table on public schema and creating a gorfs schema with another table 4 - inserting some random data into gorfs.test (*insert into gorfs.test (descr) values (unnest(array(select md5(random()::text) from generate_series(1, 30000000))));*) 5 - The data has been replicated into the slave - *PASS* 6 - Dropping the schema on the master server - *PASS* (Had to use the CASCADE option) 7 - The schema has gone on the slave server as well 8 - Checked the free space - *PASS* (*I had more free space after deleting the schema*) So it seems that only by doing a DROP SCHEMA will be enough :)
