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 1riIcD-00GLDs-83 for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Mar 2024 18:37:13 +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 1riIcA-007xwK-OQ for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Mar 2024 18:37:11 +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 1riIcA-007xwB-4P for pgsql-hackers@lists.postgresql.org; Thu, 07 Mar 2024 18:37:10 +0000 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1riIc6-003M7f-Hs for pgsql-hackers@postgresql.org; Thu, 07 Mar 2024 18:37:09 +0000 Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-a45670f9508so183424766b.0 for ; Thu, 07 Mar 2024 10:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709836625; x=1710441425; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YjkYcSeqiGn/UuxhxtglULwY/yOqJXS1+3esorS2/tE=; b=nEsTGFkHrQBpDqRy1fnBvnLgW4D8GwM10zde7E7ncFX6WdJIJ94VnuV72rJzfg6zfM z8iOxfDg7m+dvKH0w3MKtPwzwWk3qN4sG34MrXnCyWkEimheDXXF7Yx4A5Soe/pOQHrA +0g60P1rDY5L8gR4KjpEbngfaH/SAfRqN1PLBIc2dNg3Bw5FLlNmsmroNPpBVj51d7K8 2HDtVYswUlh0Le3Ng7O3/rK9qo0K+986JCtPP8boPNhPhnV8thcu3r9kUKuUTjPn5YpF uqLZcCG2/u/ZopHIYb6/UvmMkwMFek4eT4pEKHsaeN31Z7Oe9nqb0+sep9rDQQW1MBMa DGqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709836625; x=1710441425; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YjkYcSeqiGn/UuxhxtglULwY/yOqJXS1+3esorS2/tE=; b=tD5KyyGmUttKYHJk3L+PS4Es6jz1dQ42CrtCcUbVXMsh19KjuBvVjiujem3JxUSAmO Q5o8m+MhJ54NZtwsWAE5BkznelVqA/dQvgT4Q6eTOwfWu5UohYFrjmGwDmgZBKFu5bpl G8PciAAlgvmnc33kPgvjYZ6o2fd2xhowywZlpGq/cfIbgvRnUAeX2y+iOdMhfQof1ssg /GX85KE7QDFoBUSdvZVcZQTnsuSxoneeUS0INoyr2pri4DlUqaTgkcfXo+h6rFhnuPCs OZNthw1jTM/Nz1Dq+1fWXorQ59I4q7emnNvbYE7HQxcslrcObNc16kYqwo+xQHWopazm aMEA== X-Forwarded-Encrypted: i=1; AJvYcCV+0+ITFjRaxULnfdks+4f5dOds9JDpYLDFgfqFDaihtLJgZ9xQ6s7eqaADBiCJQMxBh/72UcLklFIlLQF+XsHVuobDi8McYVwMgxYF X-Gm-Message-State: AOJu0YyodrnP6I+xsMuE4MtcTaPKWoHn34wtoHkkDXQge+HuZpWuuDHC jBAqlcf/ZO9Y5aYSIPHVeEWkIiF2/rRSvtN7emiqVijWO6uBsk333Jqk4ZhnrEmV69mS2jZuQxC ZpTobK3PM2SNaOJdLj9spoFH1sfU= X-Google-Smtp-Source: AGHT+IF/PqVlQEFK70JPIY4/kFRBt+6Q6J1pWJPuryV+d2/37YF/YMq0fc5Q3L9SzuIrbFrs2W/VekXl4A3c2G9JEBE= X-Received: by 2002:a17:906:7cd7:b0:a45:af0c:e22c with SMTP id h23-20020a1709067cd700b00a45af0ce22cmr5179710ejp.37.1709836624900; Thu, 07 Mar 2024 10:37:04 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Michail Nikolaev Date: Thu, 7 Mar 2024 19:36:53 +0100 Message-ID: Subject: Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements To: Matthias van de Meent Cc: Melanie Plageman , PostgreSQL Hackers , Alvaro Herrera Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello! > I'm not a fan of this approach. Changing visibility and cleanup > semantics to only benefit R/CIC sounds like a pain to work with in > essentially all visibility-related code. I'd much rather have to deal > with another index AM, even if it takes more time: the changes in > semantics will be limited to a new plug in the index AM system and a > behaviour change in R/CIC, rather than behaviour that changes in all > visibility-checking code. Technically, this does not affect the visibility logic, only the clearing semantics. All visibility related code remains untouched. But yes, still an inelegant and a little strange-looking option. At the same time, perhaps it can be dressed in luxury somehow - for example, add as a first class citizen in ComputeXidHorizonsResult a list of blocks to clear some relations. > But regardless of second scan snapshots, I think we can worry about > that part at a later moment: The first scan phase is usually the most > expensive and takes the most time of all phases that hold snapshots, > and in the above discussion we agreed that we can already reduce the > time that a snapshot is held during that phase significantly. Sure, it > isn't great that we have to scan the table again with only a single > snapshot, but generally phase 2 doesn't have that much to do (except > when BRIN indexes are involved) so this is likely less of an issue. > And even if it is, we would still have reduced the number of > long-lived snapshots by half. Hmm, but it looks like we don't have the infrastructure to "update" xmin propagating to the horizon after the first snapshot in a transaction is taken. One option I know of is to reuse the d9d076222f5b94a85e0e318339cfc44b8f26022d (1) approach. But if this is the case, then there is no point in re-taking the snapshot again during the first phase - just apply this "if" only for the first phase - and you're done. Do you know any less-hacky way? Or is it a nice way to go? [1]: https://github.com/postgres/postgres/commit/d9d076222f5b94a85e0e318339cfc44b8f26022d#diff-8879f0173be303070ab7931db7c757c96796d84402640b9e386a4150ed97b179R1779-R1793