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 1stM6Q-00FZp4-QK for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Sep 2024 07:06:23 +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 1stM6P-004Y0M-4n for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Sep 2024 07:06:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1stM6O-004Xy6-LB for pgsql-hackers@lists.postgresql.org; Wed, 25 Sep 2024 07:06:20 +0000 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1stM6K-000ymZ-EG for pgsql-hackers@postgresql.org; Wed, 25 Sep 2024 07:06:20 +0000 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-378c16a4d3eso6841198f8f.1 for ; Wed, 25 Sep 2024 00:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20230601.gappssmtp.com; s=20230601; t=1727247976; x=1727852776; darn=postgresql.org; h=message-id:date:content-transfer-encoding:content-id:mime-version :comments:references:in-reply-to:subject:cc:to:from:from:to:cc :subject:date:message-id:reply-to; bh=0/faTLYe0WF4kUMPtgTIoP7IiGu4oYGCOuph2Jm0adY=; b=AEBI282sHVJx7++eF/DW19sRioxtEcERXqEDHrPwRiKg3fk4/WAppWHfztFWeniTwI OT3A0W0x/ezTwWRmxNsasSl9/XZ1XkEf+xOrMqsiBbZA948bswT590+DOAxdipguST9t /LVyzlS24+yxzLzQ1ZDbv98TX1rpDpySulNyVwclzrQk0f0TlaoV0bjc8xG0n0Yxj10z STcCs8SwCBQbyytrISP3Ano2IANHy1gu67oNomYPHKyk/Wz5QVl01Cy1OkEe/uUF1Swr 2iBHnSVihHO8slUEMb9chN3etm0FZGJTU4ollv22/Av+0ezAo2/RRtUZUzEbYt2fJVBa 65OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727247976; x=1727852776; h=message-id:date:content-transfer-encoding:content-id:mime-version :comments:references:in-reply-to:subject:cc:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0/faTLYe0WF4kUMPtgTIoP7IiGu4oYGCOuph2Jm0adY=; b=qmKjyW2pGZY6r4U8DSU4yEshxKcynevRB1R3sJjaVgP0MuCJYQ8c4N9nn3X5kT70DK kqi+20CbuhoIw/b03Xv1OYeDWm5xUwLyU6JSl/gKBk4x/KK3snUwLC4xXbv9KhshdiNp Lct0guGoPzcM7PkMWjd/JSQjdAsxF0WTK6c7RuiPtzV7SwSZ4LkCOPiR77niCP9xOK8S 5MMF2vQFvdVRkOe2ca7bN0wDYbBu4Q4j+XC1+OXgaHcxh4ben2P4O99KqrM7CXM6X2aJ PqsZmYVosxso/O0MMmVpSq6LDeNJ5HWP7z+ezf4MJlTeYeWCZ5JYgkNUVoxlYN4XxIkl cgBQ== X-Gm-Message-State: AOJu0YzMewlG2BuEnB5fnZVRzhnNM9aZxZ6Vp3vPeeFuVwnU+69jbE/k A0Zpr2fevv3DzAF7E6TSU/fC+v4QvmMBUvCXVRVzuINB+LOi5ztiYoAsBB3Lz4k= X-Google-Smtp-Source: AGHT+IEhYchbz+dpemWFZgHPmWK53tOb4W46iZl3Q1YKsf7EnBTDtGc49wKXDYt13voFKsrD5Wz7BQ== X-Received: by 2002:a5d:5d86:0:b0:37c:c51b:8d9c with SMTP id ffacd0b85a97d-37cc51b8ee6mr657920f8f.38.1727247976488; Wed, 25 Sep 2024 00:06:16 -0700 (PDT) Received: from antos (109-81-174-135.rct.o2.cz. [109.81.174.135]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9392f51e49sm177648866b.86.2024.09.25.00.06.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Sep 2024 00:06:16 -0700 (PDT) From: Antonin Houska To: Andres Freund cc: pgsql-hackers@postgresql.org, Noah Misch , Heikki Linnakangas , Robert Haas , Thomas Munro Subject: Re: AIO writes vs hint bits vs checksums In-reply-to: References: Comments: In-reply-to Andres Freund message dated "Tue, 24 Sep 2024 11:55:08 -0400." X-Mailer: MH-E 8.6+git; nmh 1.8; GNU Emacs 28.2.50 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2303.1727247975.1@antos> Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Sep 2024 09:06:15 +0200 Message-ID: <2305.1727247975@antos> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund wrote: > What I'd instead like to propose is to implement the right to set hint b= its as > a bit in each buffer's state, similar to BM_IO_IN_PROGRESS. Tentatively = I > named this BM_SETTING_HINTS. It's only allowed to set BM_SETTING_HINTS w= hen > BM_IO_IN_PROGRESS isn't already set and StartBufferIO has to wait for > BM_SETTING_HINTS to be unset to start IO. > = > Naively implementing this, by acquiring and releasing the permission to = set > hint bits in SetHintBits() unfortunately leads to a significant performa= nce > regression. While the performance is unaffected for OLTPish workloads li= ke > pgbench (both read and write), sequential scans of unhinted tables regre= ss > significantly, due to the per-tuple lock acquisition this would imply. An alternative approach: introduce a flag that tells that the checksum is being computed, and disallow setting hint bits when that flag is set. As l= ong as the checksum computation takes take much less time than the IO, fewer h= int bit updates should be rejected. Of course, SetHintBits() would have to update the checksum too. But if it could determine where the hint bit is located in the buffer and if "some intermediate state" of the computation was maintained for each page in sha= red buffers, then the checksum update might be cheaper than the initial computation. But I'm not sure I understand the algorithm enough. -- = Antonin Houska Web: https://www.cybertec-postgresql.com