On Fri, Sep 24, 2021 at 5:02 PM Tim wrote:
> 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 CONCURRENTL
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 tran
On 9/24/21 10:28 AM, Westwood, Giles wrote:
> At Orcid we're trying to upgrade our Postgres database (10 to 13)
> using pg_logical for no downtime. The problem we have is how long the
> initial copy is taking for the ~500GB database. If it takes say 20days
> to complete, will we need to have 20da
On Fri, Sep 24, 2021 at 3:39 PM Justin Pryzby 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-4
On Fri, Sep 24, 2021 at 03:28:50PM +0100, Westwood, Giles wrote:
> At Orcid we're trying to upgrade our Postgres database (10 to 13) using
> pg_logical for no downtime. The problem we have is how long the initial
> copy is taking for the ~500GB database. If it takes say 20days to complete,
> will w
