RE: Purging few months old data and vacuuming in production
От | Ranjith Paliyath |
---|---|
Тема | RE: Purging few months old data and vacuuming in production |
Дата | |
Msg-id | SEZPR06MB56909FBE8EF32C717E40C210C2F89@SEZPR06MB5690.apcprd06.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Purging few months old data and vacuuming in production (Ron <ronljohnsonjr@gmail.com>) |
Ответы |
Re: Purging few months old data and vacuuming in production
|
Список | pgsql-general |
Thank you very much again. > So, with this approach, is the advantage like, manual vacuuming worry may be set aside, because auto-vacuumingwould deal with the dead rows? > Theoretically, manual vacuuming is never necessary. I'd occasionally do manual vacuums (after purging a couple ofweeks of data, for example). > Disable autovacuum on a table, vacuum it, then reenable autovacuum. > > ALTER TABLE table_name SET (autovacuum_enabled = false); > VACUUM table_name; > ALTER TABLE table_name SET (autovacuum_enabled = true); Ok. For the record by record delete approach, autovacuum-ing could be the natural option. > This is because the deletion step is executed record by record in main table, with its connected record(s) deleteexecutions in rest of tables? > I don't know if you have ON DELETE CASCADE. Even if you do, you'll have to manually delete the tables not linked byFK. I'd write a PL/pgSQL procedure: pass in a PK and then delete records from the 9 tables in the proper order so as tonot throw FK constraint errors. Ok, in the case of our specific 9 tables it would finding and deleting linked records in 8 tables based on the record chosenin the main table. That is going and deleting records one by one. > Due to the infra capability that is there in this instance, > What is "infra capability"? You had a query like how beefy the hardware is - was trying to refer to the hardware capability. > the impact could be almost none!!?? > It'll use some resources, because it's a thread deleting records, but most of the records and index nodes won't bewhere new records are being inserted. > Note, though, that this will generate a lot of WAL records. Ok, thanks. We were weighing on pros and cons of the table partitioning approach. But, input on the experience you had with the partitionedapproach is something we'll need to very much consider. We'll try to see if the per record delete could be triedout once, and how it affects the DB load, with its present WAL setting. Thank you...
В списке pgsql-general по дате отправления: