Is VACUUM FULL necessary on a DROP TABLE / TRUNCATE approach for a datawarehouse
Point about TRUNCATE/COPY

Unrelated note, depending on the WAL level, wrapping the TRUNCATE and COPY in the same transaction things may go faster, because WAL will be skipped. Further the CTAS will always skip most WAL.


  In minimal level, WAL-logging of some bulk operations can be safely skipped, which can make those operations much faster (see Section 14.4.7). Operations in which this optimization can be applied include 
  source
  
  
  CREATE TABLE AS
  CREATE INDEX
  CLUSTER
  COPY into tables that were created or truncated in the same transaction
  


    BEGIN;
      TRUNCATE source_table1 
      COPY source_table1 FROM [...]
    COMMIT;


Issue of VACUUM FULL


There is no need to do a VACUUM FULL on a new table. The table is already new in those transactions so there is no need to rewrite it, as FULL does. There is also no need to VACUUM it because there are no movable rows that VACUUM will act on. When you run VACUUM FULL VERBOSE, you can see nothing was removable, and no dead rows were removed. VACUUM FULL can be useful if


you're staging INSERTS though a temp table, and adding them in batches into a dirty table. Then it can often pay off at the end of the process.
you're running UPDATE on a large batch because UPDATE generates new rows forcing VACUUM to later mark the old rows as dead.

A simple ANALYZE will work fine. This will update the statistics on the table.