RE: Query Performance after pg_restore
От | Murthy Nunna |
---|---|
Тема | RE: Query Performance after pg_restore |
Дата | |
Msg-id | DM8PR09MB6677775D7847C1B00BE60E71B89AA@DM8PR09MB6677.namprd09.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Query Performance after pg_restore (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Query Performance after pg_restore
|
Список | pgsql-admin |
Thanks, Tom. I am wondering if there is way to obtain same performance as before. Like restoring performance statistics?! Simple analyze is not helping. And Vacuum is a overkill where there are no dead tuples. I am not setting any hint bits... I can verify this in new and old if you can provide a query or some method to verify this...I still have original copy of same database on a different server for comparison. -----Original Message----- From: Tom Lane <tgl@sss.pgh.pa.us> Sent: Sunday, December 24, 2023 10:12 AM To: Murthy Nunna <mnunna@fnal.gov> Cc: pgsql-admin@postgresql.org Subject: Re: Query Performance after pg_restore Murthy Nunna <mnunna@fnal.gov> writes: > I did pg_dump of a ~20TB database followed by pg_restore. I find simple queries like select count(*) running slow. I dida select count(*) on all tables before pg_dump which took ~4 hours. After pg_restore, same thing took 32 hours. My bet is that that was setting commit hint bits, and hence incurring a lot of writes. If the data is reasonably stablethat's a one-time expense. regards, tom lane
В списке pgsql-admin по дате отправления: