Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1melan-0003NG-NV for pgsql-hackers@arkaria.postgresql.org; Sun, 24 Oct 2021 22:03:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1melal-000798-FU for pgsql-hackers@arkaria.postgresql.org; Sun, 24 Oct 2021 22:03:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1melal-00078x-0I for pgsql-hackers@lists.postgresql.org; Sun, 24 Oct 2021 22:03:47 +0000 Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1melad-0001KU-Ny for pgsql-hackers@postgresql.org; Sun, 24 Oct 2021 22:03:45 +0000 Received: by mail-io1-xd34.google.com with SMTP id 188so12975379iou.12 for ; Sun, 24 Oct 2021 15:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=C7oWSGUnNJSjpSWa0JnaqfPnK8PmbDwwGa2Siv6RrB8=; b=oCictfI6Ce/E20cnmq4aUEZE0FCs6yH7kA7O6MZnD1PN19JjS7Nq7cgkc8+1wMvTTC Di4aAhjInNXLcWD5qi11NOEEZfUJUyEDdEqn74H54HLbWJPHgeRi/Tp8DKfBNksNZf06 ZVo2Ia5hhSyjx1rdUg9j010oMJq5MTsZROOLl/MKWbolOg1DGv7ufK/x6VBKlkJ2aGIF ppHx1ypRmufz34UdvfsuVxm5GIX5L/9b0B7rRr5OlcnsQbEIZTGDMSR/JHkOOZC+9tF/ Vcfbw6eYgBpbPpOJ1BpZ3CxSFeUGG32UIE80RkBL+GnZMQkImXbk6L8udNWjGpjTJZY5 o/FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=C7oWSGUnNJSjpSWa0JnaqfPnK8PmbDwwGa2Siv6RrB8=; b=MkWUkbMbO6sSG8fnIq7Mrf34qKmNamnAI/Tn41plOICJE34/PSH51jWThexdZRZPAA vGkE5QuPHUE4x9YYvwgxDiDY/YbZ2l3OzN4fCYxVo45Z8NHCxd30WnMRhM0VGEDGHNQ6 qg1Ts+bKlx1QpMKofxoV5YKTUOhJcU9D6xssdO+US+GScV9Nar0DFAHrm3CV7ZBodSow we6DmBORhSMyBSQmeN33FV3S5Swd9sJCf+OgssK1bnVcifXs3jDU7KXjT+p7vNOhH4WB HqqiTcAqdAt0t2KuBmGklqxpAcfJz3bGPX2HlVS1cJ+EtwK9+60bDB9SKtY7uR2G6KRT lD9Q== X-Gm-Message-State: AOAM533pKbBrD1tZJ/8wX0fQAZuBzYiWElZw+hAC3LtSLlplfGzJYdl0 2RfTXwA0cdiFIJ2mrDc7ngP/BXQXMeXzRw== X-Google-Smtp-Source: ABdhPJwInqhFAr+JU8X1c0XAZojE9eddqGrHOn7v8FFILzqbDgl9lX/b8rdFD4Dn2WgZSjhTm1eBCA== X-Received: by 2002:a02:b885:: with SMTP id p5mr4510727jam.81.1635113018960; Sun, 24 Oct 2021 15:03:38 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id s7sm7919497ilu.19.2021.10.24.15.03.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Oct 2021 15:03:38 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 04FBD800E68; Sun, 24 Oct 2021 17:03:37 -0500 (CDT) Date: Sun, 24 Oct 2021 17:03:37 -0500 From: Justin Pryzby To: Tom Lane Cc: Hans Buschmann , pgsql-hackers@postgresql.org, Andres Freund Subject: Re: Assorted improvements in pg_dump Message-ID: <20211024220337.GN9856@telsasoft.com> References: <7d7eb6128f40401d81b3b7a898b6b4de@W2012-02.nidsa.loc> <3780613.1635109855@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3780613.1635109855@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Oct 24, 2021 at 05:10:55PM -0400, Tom Lane wrote: > 0003 is the same except I added a missing free(). > > 0004 is a new patch based on an idea from Andres Freund [1]: > in the functions that repetitively issue the same query against > different tables, issue just one query and use a WHERE clause > to restrict the output to the tables we care about. I was > skeptical about this to start with, but it turns out to be > quite a spectacular win. On my machine, the time to pg_dump > the regression database (with "-s") drops from 0.91 seconds > to 0.39 seconds. For a database with 10000 toy tables, the > time drops from 18.1 seconds to 2.3 seconds. + if (tbloids->len > 1) + appendPQExpBufferChar(tbloids, ','); + appendPQExpBuffer(tbloids, "%u", tbinfo->dobj.catId.oid); I think this should say + if (tbloids->len > 0) That doesn't matter much since catalogs aren't dumped as such, and we tend to count in base 10 and not base 10000. BTW, the ACL patch makes the overhead 6x lower (6.9sec vs 1.2sec) for pg_dump -t of a single, small table. Thanks for that. -- Justin