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  (Ron Johnson <ronljohnsonjr@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Scott Ribe
Дата:
Сообщение: Re: Timestamps in outputs
Следующее
От: Ron Johnson
Дата:
Сообщение: Re: Query Performance after pg_restore