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 :)