This is the view that you need to check:

select n_live_tup, n_dead_tup, relname from pg_stat_all_tables;  

Don't use autovacuum. Greenplum isn't PostgreSQL and autovacuum does not work in the database. I highly recommend not tagging Greenplum posts with PostgreSQL because you will likely get incorrect information. It would be like posting a question about OSX and also tagging BSD.

Vacuum Heap tables with bloat:

psql -t -A -c "SELECT E'VACUUM \"' || bdinspname || E'\".\"' || bdirelname || E'\";' FROM gp_toolkit.gp_bloat_diag WHERE bdinspname <> 'pg_catalog'" | psql -e

But most all of your tables in Greenplum will likely not be heap based which uses MVCC and instead use "Append Optimized" or AO for short. It uses a visibility map to hide deleted rows and the files are smaller so it is faster. It also allows the table to be compressed and column oriented.

AO tables also need maintenance but unlike heap tables, it has a compaction threshold built in controlled by gp_appendonly_compaction_threshold GUC. Just VACUUM all AO tables and the database will automatically rebuild the table if the percentage of hidden rows exceeds 10%.

Greenplum still suffers from the freeze age problem that was inherited from PostgreSQL. This script typically won't return any rows but on older installations with tables that haven't been touched in a very long time, you might start to vacuum tables.

vacuum_freeze_min_age=$(psql -t -A -c "show vacuum_freeze_min_age;")
psql -t -A -c "SELECT E'VACUUM \"' || n.nspname || E'\".\"' || c.relname || E'\";' FROM pg_class c join pg_namespace n ON c.relnamespace = n.oid WHERE age(relfrozenxid) > $vacuum_freeze_min_age AND c.relkind = 'r'" | psql -e

While you are at it, you should schedule analyzedb to analyze all tables on a regular basis. Example:

analyzedb -d gpadmin -s tpcds

Don't forget the catalog!

psql -t -A -c "SELECT E'VACUUM ANALYZE \"' || n.nspname || E'\".\"' || c.relname || E'\";' FROM pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid WHERE n.nspname = 'pg_catalog' AND c.relkind = 'r'" | psql -e

This reindexes the catalog indexes:

reindexdb -s

The data in pg_stat_user_tables is not transactional. It is reset to zero/NULL whenever the system crashes or has an unclean shutdown (and can also be reset manually). That has presumably happened.

The high freepercent reported by pgstattuple would seem to indicate that the table has been vacuumed at some point, now forgotten about. You could check the freespace map to make sure PostgreSQL knows how to find this free space when it needs it.