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 1oarOY-0007dg-Kq for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Sep 2022 04:31:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oarOX-0002gV-7r for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Sep 2022 04:31:33 +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 1oarOW-0002gL-TF for pgsql-hackers@lists.postgresql.org; Wed, 21 Sep 2022 04:31:32 +0000 Received: from mail-pg1-x536.google.com ([2607:f8b0:4864:20::536]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oarOU-0006Ik-6e for pgsql-hackers@postgresql.org; Wed, 21 Sep 2022 04:31:31 +0000 Received: by mail-pg1-x536.google.com with SMTP id v4so4727225pgi.10 for ; Tue, 20 Sep 2022 21:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=ZKoK0wWbB4HKxkg++5cNOXaAOJpS6ThCuC9Fumyt+0I=; b=FEvfleixS0a3zqDpwkfLFrfu88qGPxiSyIDoTE3I3wgc8z4wvrKItpUnt5hesXrkMH LW+hdxz/BDx1KwxMoQnQIF3XrGfK0Dac2nLpybPEh/TdqtQmYy2F3298N8qJhlcwVoc0 oh8P2tZsAEfScGjQ3vEHYaGl9AtgIHrPb7o1Su5lar9iPvBh1YhtxXIGcjTiSXyqGFrI xc0duzk9gOd4GJvAFuMmTrpsB1FzjU2e5moJvZNXtSjPxQ84FRh3QGl1ueaF/CKhOfPg 7SSt3kbb++ThyrhutB3qBBrfgbn0Bax5WR30boytrB4Emq2C7/EofbVC7vykXQ4pbt+0 yPcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=ZKoK0wWbB4HKxkg++5cNOXaAOJpS6ThCuC9Fumyt+0I=; b=gC+kAIgxOFRg4YpY2oBRAGEIZFl7RGHA16VHtLpwnHc++nFlyOimFvCsFHtvhpv8HZ 4v2deDT9F40OM9oiwTNcQCIXKRpBYWX8OCb+Hgjku4RS0SyEr+kGpAALVQG2mWZZ2MQ1 j67DJ8I9f3fux6c6CW75lwCnTWn5Z353uNtYBZ6TfBjXjvEKK8bXl+yREjgiF9LGz34H SIcOohoFmpWUm8OrMAZjODNNwOH6JnxdicHeLLTnWytNKxjIzH7Hyh+0V800mar7rSMI 8aT/++SdQ8r4EDMsaIpM6ccf2FVRUsfiOh6nzG951awJizEV/BKEhYtJNoBExZ0vKuwT aEtg== X-Gm-Message-State: ACrzQf2HF4ulinIT5pkNMUXTPXWrJErrDko44noVuDfLgB4mTuK1+ccu VhyjMiaURgtR/IIr43/3vnY= X-Google-Smtp-Source: AMsMyM4ZTS998jJtCEHRObKJoxL3Oo8fXtG9aqemrCVAV3NgVhZaX8Ut9zfIMHhTtDS5RejUuOLE+Q== X-Received: by 2002:a65:6e87:0:b0:438:e26c:167a with SMTP id bm7-20020a656e87000000b00438e26c167amr22417609pgb.421.1663734688772; Tue, 20 Sep 2022 21:31:28 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id c37-20020a631c65000000b0043949b480a8sm820372pgm.29.2022.09.20.21.31.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Sep 2022 21:31:28 -0700 (PDT) Date: Tue, 20 Sep 2022 21:31:26 -0700 From: Nathan Bossart To: Michael Paquier Cc: Robert Haas , Stephen Frost , Bharath Rupireddy , "David G. Johnston" , Kyotaro Horiguchi , "pgsql-hackers@postgresql.org" Subject: Re: predefined role(s) for VACUUM and ANALYZE Message-ID: <20220921043126.GA382738@nathanxps13> References: <20220907211343.GE26002@tamriel.snowman.net> <20220907221103.GA2095022@nathanxps13> <20220920035147.GA114383@nathanxps13> <20220920180533.GA205278@nathanxps13> <20220920233117.GA378596@nathanxps13> <20220920235010.GB378596@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Sep 21, 2022 at 10:31:47AM +0900, Michael Paquier wrote: > Did you just run an aclupdate()? 4% for aclitem[] sounds like quite a > number to me :/ It may be worth looking at if these operations could > be locally optimized more, as well. I'd like to think that we could > live with that to free up enough bits in AclItems for the next 20 > years, anyway. Any opinions? Yes, the test was mostly for aclupdate(). Looking at that function, I bet most of its time is spent in palloc0() and memcpy(). It might be possible to replace the linear search if the array was sorted, but I'm skeptical that will help much. In the end, I'm not it's worth worrying too much about 2,000 calls to aclupdate() with an array of 2,000 ACLs taking 5.3 seconds instead of 5.1 seconds. I bet a more pressing concern is the calls to aclmask() since checking privileges is probably done more frequently than updating them. That appears to use a linear search, too, so maybe sorting the aclitem arrays is actually worth exploring. I still doubt there will be much noticeable impact from expanding AclMode outside of the most extreme cases. > For the column sizes of the catalogs, I was wondering about how > pg_column_size() changes when they hold ACL information. Unoptimized > alignment could cause an unnecessary increase in the structure sizes, > so the addition of new fields or changes in object size could have > unexpected side effects. After a few tests, I haven't discovered any changes to the output of pg_column_size(). -- Nathan Bossart Amazon Web Services: https://aws.amazon.com