Re: optimizing pg_upgrade's once-in-each-database steps

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: optimizing pg_upgrade's once-in-each-database steps
Date: 2024-07-08 15:22:08
Message-ID: ZowEIGd0lLKh16qe@nathan
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

As I mentioned elsewhere [0], here's a first attempt at parallelizing the
data type checks. I was worried that I might have to refactor Daniel's
work in commit 347758b quite significantly, but I was able to avoid that by
using a set of generic callbacks and providing each task step an index to
the data_types_usage_checks array.

[0] https://postgr.es/m/Zov5kHbEyDMuHJI_%40nathan

--
nathan

Attachment Content-Type Size
v3-0001-introduce-framework-for-parallelizing-pg_upgrade-.patch text/plain 10.0 KB
v3-0002-use-new-pg_upgrade-async-API-for-subscription-sta.patch text/plain 8.8 KB
v3-0003-move-live_check-variable-to-user_opts.patch text/plain 11.8 KB
v3-0004-use-new-pg_upgrade-async-API-for-retrieving-relin.patch text/plain 11.1 KB
v3-0005-use-new-pg_upgrade-async-API-to-parallelize-getti.patch text/plain 3.4 KB
v3-0006-use-new-pg_upgrade-async-API-to-parallelize-repor.patch text/plain 3.4 KB
v3-0007-parallelize-data-type-checks-in-pg_upgrade.patch text/plain 12.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2024-07-08 15:25:43 Re: 回复: An implementation of multi-key sort
Previous Message Tomas Vondra 2024-07-08 15:14:38 Re: 回复: An implementation of multi-key sort