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 1jJ7Uj-0005jm-2j for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2020 03:23:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jJ7Uh-0003qC-Ul for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2020 03:23:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jJ7Uh-0003mr-NX for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2020 03:23:15 +0000 Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jJ7Ue-0005bq-Cl for pgsql-hackers@postgresql.org; Tue, 31 Mar 2020 03:23:15 +0000 Received: by mail-qt1-x82f.google.com with SMTP id z24so15956941qtu.4 for ; Mon, 30 Mar 2020 20:23:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=s9uLs8Pn8sbnxowPYz2LBDyyAiNERPGF+g65yjDUhZo=; b=csbfayMd/TOzXMojHWpgwL8cbfi5QSEAlky3iyfXtAORM1JA+q+uzNLaGb7nW4O0U/ 6dK+TPEkYa//2/mHw281sf/Z+FTFXxNrZfpPNGg77inAruIoqCU80l+yzGyYBV2//OjZ sSgGCGZFOutn+hEZarW6GKOysX6qcts/uEMBMKOISjX5ji6/TTq+Y+shl86Um7SwJkzq hURlH+ihvuPaqDjKNOXHsiQu+ttzg4obUusAjEzt4k81npO34u4pLzAZuhWgKrPXQiGv pnbbj1uFzi430CkH36KmkrMkT0ElwcPnVdt+Ope4LZbp8xwVrp77tC7m12yjBs+x4IEa KSKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=s9uLs8Pn8sbnxowPYz2LBDyyAiNERPGF+g65yjDUhZo=; b=kbpC68fZUQcrlzWbtKsRQx7+8AtYfAgQbuYKr54ipxN7sx+l1b6kFZdRnA1J7U0bL+ QRSppTpqiNM5w67kqADJD8fAT2fgawBhQp3cgKc6i8q2CoIXxh1XWTuuC5fV32JhFTc7 Laqpzbtnr674RM4ax5KZSXsavKi+JCSS3v7TzKgK0edw3QfBEkfLkMmFQXFg4wU+hd4x IAIl00orPGDmqH59mSHYU1e8CxA7hhBQ1kO4NW1ykSF4/RbdAL0lFItlUfarbQo931hc uE6r5E2hYdopy+HUoKasWg9Tww4O0uFnR8m4jnGAs9AZVrVGVR8m7fGcnLolShRGY7P4 S5cA== X-Gm-Message-State: ANhLgQ1B0JVFase0FpxjjCkVoffAXod/jBw/SUtlOyh+EfD3Dk9tnaud o1M+DGPXoooH+fYbDD8kptmt+1rN+/I= X-Google-Smtp-Source: ADFU+vtU1QKVSp2sqXYsH9F1Y887Rr+ylRewS2kRApLJTvhfnYe3ySwaosdV3nA0dwFktFo82XFpaA== X-Received: by 2002:ac8:6c50:: with SMTP id z16mr3158773qtu.154.1585624990455; Mon, 30 Mar 2020 20:23:10 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id l13sm12739789qtu.66.2020.03.30.20.23.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Mar 2020 20:23:09 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 2754D800C2E; Mon, 30 Mar 2020 22:23:08 -0500 (CDT) Date: Mon, 30 Mar 2020 22:23:08 -0500 From: Justin Pryzby To: Amit Kapila Cc: Alvaro Herrera , Masahiko Sawada , Andres Freund , Michael Paquier , pgsql-hackers Subject: Re: error context for vacuum to include block number Message-ID: <20200331032307.GD14618@telsasoft.com> References: <20200326221752.GR17431@telsasoft.com> <20200326224951.GA20085@alvherre.pgsql> <20200326233321.GA15224@telsasoft.com> <20200330162616.GP20103@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Mar 31, 2020 at 07:50:45AM +0530, Amit Kapila wrote: > On Mon, Mar 30, 2020 at 9:56 PM Justin Pryzby wrote: > > > > On Mon, Mar 30, 2020 at 02:31:53PM +0530, Amit Kapila wrote: > > > The v37-0003-Avoid-some-calls-to-RelationGetRelationName.patch looks > > > good to me. I have added the commit message in the patch. > > > > I realized the 0003 patch has an error in lazy_vacuum_index; it should be: > > > > - RelationGetRelationName(indrel), > > + vacrelstats->indname, > > > > Hmm, it is like that in the patch I have sent yesterday. Are you > referring to the patch I have sent yesterday or some older version? Oh good. That was a recent fix I made, and I was afraid I'd never sent it, and not sure if you'd used it. Looks like it was fixed since v36... As you can see, I'm losing track of my branches. It will be nice to finally put this to rest. > One thing I have noticed is that there is some saving by using > vacrelstats->relnamespace as that avoids sys cache lookup. OTOH, > using vacrelstats->relname doesn't save much, but maybe for the sake > of consistency, we can use it. Mostly I wrote that to avoid repeatedly calling functions/macro with long name. I consider it a minor cleanup. I think we should put them to use. The LVRelStats describes them as not being specifically for the error context. -- Justin