Closed brauliobo closed 7 years ago
Just as a sidenote, I won't be using pg_repack anymore, let me share the reasons so that you can consider future improvementes. The lack of incremental repacking requires too much resources (CPU, disk and free space) from the database. This makes repacking big tables inviable in busy and live databases. Also the configuration seems not very simple on multiuser environments.
incremental repack is what autovacuum is about.
@danbst autovacuum doesn't reorder according to clustered indexes
have you considered partitioning on cluster key (in some cases it is possible)?
I don't know of anything in PG world that could do incremental CLUSTER.
never really understood how partitions works and how to use them... might be a good thing though, I'm afraid they require changing the applications
For us, executing this as the rds_superuser role worked:
CREATE EXTENSION pg_repack;
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT INSERT ON TABLES TO PUBLIC;
ALTER DEFAULT PRIVILEGES IN SCHEMA repack GRANT USAGE, SELECT ON SEQUENCES TO PUBLIC;
See: http://engineering.ometria.com/2018/01/29/using-pg_repack-with-aws-postgres-rds/
@electric-al
This link of post (http://engineering.ometria.com/2018/01/29/using-pg_repack-with-aws-postgres-rds/) is gone away. Can you post again?
After enabling pg_repack on RDS, I had to change the owner of the functions according to https://dba.stackexchange.com/questions/182840/repacking-rds-database-with-pg-repack-isnt-online/182841 to fix the error
Sequel::DatabaseError: PG::InsufficientPrivilege: ERROR: permission denied for relation log_705387
on inserts.But then that created another INSERT error:
ERROR: must be superuser to use repack_trigger function
, so I rolling back the permissions to the superuser.How to work then with multiple users and ensure they can INSERT data when pg_repack is enabled??