Re: Performance for initial copy when using pg_logical to upgrade Postgres

Поиск
Список
Период
Сортировка
От Tim
Тема Re: Performance for initial copy when using pg_logical to upgrade Postgres
Дата
Msg-id CAKhLO5jd=n3WBGoRU9inqZgQxPN6gsg_crLwq5SgJ0Ky45_8cw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance for initial copy when using pg_logical to upgrade Postgres  ("Westwood, Giles" <g.westwood@orcid.org>)
Ответы Re: Performance for initial copy when using pg_logical to upgrade Postgres  ("Westwood, Giles" <g.westwood@orcid.org>)
Список pgsql-performance
Дерево обсуждения
I'm currently doing this with a 2.2 TB database. 

Best way IMO is to (UPDATE pg_index SET indisready = false ... ) for non PK indexes for the largest tables. Then just set it back to indisready = true after its done and run a REINDEX CONCURRENTLY on the indexes that were disabled.

Got about a transfer speed of 100GB per 50 minutes with this method with consistent results.

On Fri, Sep 24, 2021 at 11:49 AM Westwood, Giles <g.westwood@orcid.org> wrote:




On Fri, Sep 24, 2021 at 3:39 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
On Fri, Sep 24, 2021 at 03:28:50PM +0100, Westwood, Giles wrote:

Did you see this thread and its suggestions to 1) set bulk load parameters;
and, 2) drop indexes and FKs ?

https://www.postgresql.org/message-id/flat/4A8EFC4E-A264-457D-A8E7-AE324ED9ABD4@thebuild.com


I did actually but I wanted to avoid getting my hands dirty with anything schema wise. I've found another person with another similar situation:-


В списке pgsql-performance по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Performance for initial copy when using pg_logical to upgrade Postgres
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Big Performance drop of Exceptions in UDFs between V11.2 and 13.4