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 1mNrKn-0003JE-1x for pgsql-bugs@arkaria.postgresql.org; Wed, 08 Sep 2021 06:45:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mNrKl-0004HF-Dg for pgsql-bugs@arkaria.postgresql.org; Wed, 08 Sep 2021 06:45:23 +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 1mNrKk-0004H7-WD for pgsql-bugs@lists.postgresql.org; Wed, 08 Sep 2021 06:45:23 +0000 Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mNrKi-0004Hi-B2 for pgsql-bugs@lists.postgresql.org; Wed, 08 Sep 2021 06:45:21 +0000 Received: by mail-qt1-x832.google.com with SMTP id b4so1052075qtx.0 for ; Tue, 07 Sep 2021 23:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=/f70eEGqeB18ywlAruKlsjYnN8Edql2KdDa8byiULKg=; b=XCKfeyPNm7cmRV1Y9Uz9WoZVhhLAhW35BM/tZuvr/gESeO3z4iqMaW8nEx+oYQDrMe BjF2wDLz6VkFSXoe7Vq3speffPpt2/J+oZjzoHbsLJCzw9/D4acS3ri/lr2DPI/4buMC FYoltYj08eW6QDJnFXApzb73htr3cqwu+QLUE= 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:content-transfer-encoding :in-reply-to:user-agent; bh=/f70eEGqeB18ywlAruKlsjYnN8Edql2KdDa8byiULKg=; b=rrHCnjflr8WTlY5I/gjPR6G8qJBuUdnZdzMyurg1rSDY/+oCzDUOLv+QJ2rHiQP5fq Xpe4tVp81jk7xeL/aaJvAS/oiLj18kFkmp/sbMWoOufI+frMJ9zJfZsmVbRJLgXxQJdr xkBQC4kKCxuVr+EtAmj3g7NSQrvzpvR3PIjkb0ubZFBWYaRehBu5/vaCnZ5s1gsoGYZk WWUJOs6POUNUeXasEvsLxhuiaeICLz3MQ8D//FY3egyzRT4Ze/66Wfs6duXfbCxb3Hyy y9bCBtxOi12aDsVk65WCAan8xuoIkT6v43TtNGFb2400o6KflZ9IctJB29+rWEBrkVw3 oGmQ== X-Gm-Message-State: AOAM530C3hoXBOhI3pULopAWoxxXI/Sal9WC4s26UIHtjGZrvzpiAnk0 t9/LqJjhxjniP/rGGlUW2XNm5w== X-Google-Smtp-Source: ABdhPJz/+55+KBjsNCX98vQezclhBChgbXXcFBVgRSbMb3WoSiA30cOAmrek/l+cPCOp+cxjofbL3w== X-Received: by 2002:ac8:5f09:: with SMTP id x9mr2106644qta.103.1631083519119; Tue, 07 Sep 2021 23:45:19 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::46]) by smtp.gmail.com with ESMTPSA id v8sm933418qtk.49.2021.09.07.23.45.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Sep 2021 23:45:18 -0700 (PDT) Date: Tue, 7 Sep 2021 23:45:15 -0700 From: Noah Misch To: Andres Freund , Andrey Borodin Cc: PostgreSQL mailing lists , Michael Paquier , Tom Lane , Peter Geoghegan Subject: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data Message-ID: <20210908064515.GA2496820@rfd.leadboat.com> References: <20210807221957.GA169359@rfd.leadboat.com> <5E041A70-4946-489C-9B6D-764DF627A92D@yandex-team.ru> <20210808163752.GB23176@rfd.leadboat.com> <20210814221328.GA146778@rfd.leadboat.com> <20210815084535.GA1227376@rfd.leadboat.com> <20210815134547.3okuz6ktvu4qf7ig@alap3.anarazel.de> <15936F8A-0436-40C8-9D1A-4A4623681554@yandex-team.ru> <20210829180913.ghojzzsgkqgm7vki@alap3.anarazel.de> <364BAA98-1A3F-4C39-B0D9-ED8C40EA902D@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <364BAA98-1A3F-4C39-B0D9-ED8C40EA902D@yandex-team.ru> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Aug 29, 2021 at 11:38:03PM +0500, Andrey Borodin wrote: > > 29 авг. 2021 г., в 23:09, Andres Freund написал(а): > >>> It seems like it's going to add a substantial amount of work even when > >>> no 2PC xacts are involved? > >> Only if 2PCs are enabled. > > > > I don't think that's good enough. Plenty of systems have 2PC enabled but very > > few if any transactions end up as 2PC ones. > Best optimisation I can imagine here is to gather all vxids with unknown xids and search for them in one call to TwoPhaseGetXidByVXid() with one LWLockAcquire(TwoPhaseStateLock, LW_SHARED). > > Does it worth the complexity? https://www.postgresql.org/search/?m=1&q=TwoPhaseStateLock&l=&d=-1&s=r suggests this is the first postgresql.org discussion of TwoPhaseStateLock as a bottleneck. Nonetheless, if Andres Freund finds it's worth the complexity, then I'm content with it. I'd certainly expect some performance benefit. Andres, what do you think? We could start with an unlocked scan of the twophase shared memory. If the unlocked scan finds a potential match, acquire TwoPhaseStateLock and repeat the scan. Otherwise, we don't need the locked scan, because we can deduce that the locked scan would find nothing. I'm not fond of relying on such reasoning without a known-strong performance need, but it's an alternative.