Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sZHIQ-00HU4p-Ov for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Jul 2024 21:55:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sZHIN-00EXsU-3r for pgsql-hackers@arkaria.postgresql.org; Wed, 31 Jul 2024 21:55:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sZHIM-00EXqo-PT for pgsql-hackers@lists.postgresql.org; Wed, 31 Jul 2024 21:55:42 +0000 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sZHIG-002RXF-8K for pgsql-hackers@postgresql.org; Wed, 31 Jul 2024 21:55:41 +0000 Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-3685afd0c56so3182411f8f.1 for ; Wed, 31 Jul 2024 14:55:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722462935; x=1723067735; darn=postgresql.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=tqb2Ib04RzbmDT5wP5L4yc/L06nBUvl0i8Wf3l62ayU=; b=Fzak+azbX5QCbMRZlRQtcCUmq/GGq0EveV159ATkVug9+9N8TlT4rnI8qV94/G1YBp HvSj7Cd5eKpv4k049tyRsvjiIZ83KX/BfrD/4rPCm1agYeQmBZ+xLqys9bq7tNPiaPrZ v5HXKNnDLCEoZjMumAnHIl7wwEj9Q07gPQH5AuSVm/jFJxU9jStBPlR2GOcr/tjDWvL+ X04gmW/FrokXxJGT3fRKWjGo78Vl9EQz/9hQAgmfn0hKvfHwVjen4qQcmzRBELJ/OdSR +DnBkgwcDXQkOzbsnIqo8SlgLN8xZ+ADPuWQQw8bcnzIYtbE8dZDBmBIDQ+yaHWlb7Nf HGBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722462935; x=1723067735; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tqb2Ib04RzbmDT5wP5L4yc/L06nBUvl0i8Wf3l62ayU=; b=XCWsSrI2XaiW7PekhjJjN5bPyVbgXhcfN/a78TjzSWk/v4FJgr5R2Dsh3ESkfHztzd iE5XdS/8j8rzEiRptLiK6lWXtTO+edTevwvcZZeOiWq907z6v9ylTbFhme1OYR6du4Bd 83aHWxjt3ws0XMpf5DHNSxo+IYxUO0QzlA4xTQ63zGupCtrgAFXWTLen4YIXnkp7YLse UdMmvrimzDkPGzN6O7rzyaayX73UzVYcdN5Yr0Da9ya+z0eiQrZXFwp2tK+bNanmFRfD TUUNhS/QLuro57nlkgwoydrk0IiGt/SzESFFzdnQTABk8tdH4KgfoErUx8rCLoY6neXL PfCQ== X-Forwarded-Encrypted: i=1; AJvYcCVLmEzvRvsgjXRkUdZLPDzInRziRlnztbg2bqGaxiXjXrdxGZBrHc6fgoAL8ujbxRI48yNIoPzkQFyvp8DokPcYAqBElpwBOAoJbuST X-Gm-Message-State: AOJu0YybRGn9fTwWyzTchJiiG9MoQato0nFAn8v9CBZhH7oh55fZ8Afx doh/jixuIqLgSZZgMgJL4RDltcfST79AgTRtZbtnjizZ2LzMFauj+AxuoLRm X-Google-Smtp-Source: AGHT+IGLxtFojj8/czELsXaiFmsomxg3nh+N6YIleblkmiPoUFrYzeWEbdnOUiImF9ZNfyGUEB3jqA== X-Received: by 2002:a5d:440d:0:b0:368:446a:62ba with SMTP id ffacd0b85a97d-36baace09c2mr305364f8f.17.1722462934300; Wed, 31 Jul 2024 14:55:34 -0700 (PDT) Received: from ?IPV6:2a01:4b00:c00c:a500:daed:5400:ac8:dbfb? ([2a01:4b00:c00c:a500:daed:5400:ac8:dbfb]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-36b367e07ffsm17860537f8f.43.2024.07.31.14.55.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Jul 2024 14:55:33 -0700 (PDT) Message-ID: <10c1c8dd-4685-46d4-80be-56bdfca8659a@gmail.com> Date: Wed, 31 Jul 2024 22:55:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: optimizing pg_upgrade's once-in-each-database steps To: Nathan Bossart , Daniel Gustafsson Cc: Robert Haas , Jeff Davis , PostgreSQL Hackers References: <20240517012408.GA1691322@nathanxps13> <26742670-9539-4F30-B6FA-9C1DB743BC23@yesql.se> <4493D323-9726-48F7-A702-E71FB991F76B@yesql.se> Content-Language: en-US From: Ilya Gladyshev In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 22.07.2024 21:07, Nathan Bossart wrote: > On Fri, Jul 19, 2024 at 04:21:37PM -0500, Nathan Bossart wrote: >> However, while looking into this, I noticed that only one get_query >> callback (get_db_subscription_count()) actually customizes the generated >> query using information in the provided DbInfo. AFAICT we can do this >> particular step without running a query in each database, as I mentioned >> elsewhere [0]. That should speed things up a bit and allow us to simplify >> the AsyncTask code. >> >> With that, if we are willing to assume that a given get_query callback will >> generate the same string for all databases (and I think we should), we can >> run the callback once and save the string in the step for dispatch_query() >> to use. This would look more like what you suggested in the quoted text. > Here is a new patch set. I've included the latest revision of the patch to > fix get_db_subscription_count() from the other thread [0] as 0001 since I > expect that to be committed soon. I've also moved the patch that moves the > "live_check" variable to "user_opts" to 0002 since I plan on committing > that sooner than later, too. Otherwise, I've tried to address all feedback > provided thus far. > > [0] https://commitfest.postgresql.org/49/5135/ > Hi, I like your idea of parallelizing these checks with async libpq API, thanks for working on it. The patch doesn't apply cleanly on master anymore, but I've rebased locally and taken it for a quick spin with a pg16 instance of 1000 empty databases. Didn't see any regressions with -j 1, there's some speedup with -j 8 (33 sec vs 8 sec for these checks). One thing that I noticed that could be improved is we could start a new connection right away after having run all query callbacks for the current connection in process_slot, instead of just returning and establishing the new connection only on the next iteration of the loop in async_task_run after potentially sleeping on select. +1 to Jeff's suggestion that perhaps we could reuse connections, but perhaps that's a separate story. Regards, Ilya