I've been following the official documentation for pg_partman, specifically partitoning an existing table using offline partitioning (https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman_howto_native.md).
The reason for this change is we wanted to move from ID based list partitioning to monthly range partitioning on a new timestamptz column.
My source and destination table are essentially identical. The only change I have made is the partition column has changed from an ID (using list partitioning) to a newly created timestamptz column (using range partitioning), however this new column exists on both source and destination tables now.
My issue is running
CALL partman.partition_data_proc(p_parent_table := 'public.partitioned_table', p_interval := '1000', p_batch := 200, p_source_table := 'public.nonpartitioned_table');
produces the following output:
Total rows moved: 0
Ensure to VACUUM ANALYZE the parent (and source table if used) after partitioning data
Despite the source table having hundreds of thousands of rows to move.
Is there any way to enable verbose debugging or getting some indication of why this proc is not moving rows?
Edit:
Testing a straight insert/select moved the data fine, but this seems like a bad way to do things.
insert into public.partitioned_table select * from public.nonpartitioned_table;
