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 1svM5t-00EOrY-0R for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Sep 2024 19:30:05 +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 1svM5s-004hqM-0w for pgsql-hackers@arkaria.postgresql.org; Mon, 30 Sep 2024 19:30:04 +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 1svM5r-004hqE-PH for pgsql-hackers@lists.postgresql.org; Mon, 30 Sep 2024 19:30:03 +0000 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1svM5k-001pys-TW for pgsql-hackers@postgresql.org; Mon, 30 Sep 2024 19:30:02 +0000 Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-7d4fa972cbeso3453907a12.2 for ; Mon, 30 Sep 2024 12:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; t=1727724596; x=1728329396; darn=postgresql.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=gNGzvN1+H4g29dMB6pt/c98HjZYeMKvv5bMxH11Gl1Y=; b=FLsK0X7ibBXqmGUZfy2J25S3usO97CXbQqVw1Gat34MDtPwM67JNWnoAOYRPy5JAqo Clr6P8pRKERv3uAhrAeop+ZChn1h0Fzm8F1kEd0rlAjvLu38kWVICImMhAUo2kde8skJ YJu4wAKdh/5gY1YK4lcuBUuyXZN7EJaaTzc50= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727724596; x=1728329396; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gNGzvN1+H4g29dMB6pt/c98HjZYeMKvv5bMxH11Gl1Y=; b=cvXjunsVu0V148zEpESg6/b/Ga8JecGJrEHg5LLqpNoownPDBAJNK9xYvvBV7UxvCA YQVmoC6Bl+hox8tyXuTR4rSDy3v5tg0NKqnGK1xiblt8xaPl3xDYfwwAEIgGvyJSj1Pm +dbsAxApH0x9bq26HwiqLykuEhgwvFoaB2R5M/cyDo2l92iWZTc+K7G6dQDKHEj0259P SHeHF8u0m3cnHJnZnR0wVX51IfVsv5u7gVae/ZETSHAICWccjr+aLvAd3tikgSQVG02R NbZFwxyrSbEEYCcFpJM3mbfMvhguH+YROzb0NJdn7jZQRS7iJneyAQsNpkvQyq9adSPK IDPA== X-Gm-Message-State: AOJu0Ywnc0fVN/K57mUAld/ALYMpwMXRH4b16Cg/c7uh1Z1DOw9kZhg9 RvBIo92no8uHhVIdI7m0Ja/fQxlLsscWAjmdyR2OWrju6q/Nkd5MkcjTC/qCig== X-Google-Smtp-Source: AGHT+IEuIVOzQIN96gthzshoSINihJSnrl+4SN1X/AKD3F6MUfwcl3p/MYlVQ0rSsfGiSw447Zt6sg== X-Received: by 2002:a05:6a21:3489:b0:1d2:f039:4638 with SMTP id adf61e73a8af0-1d4fa6cfbc4mr21583111637.23.1727724595921; Mon, 30 Sep 2024 12:29:55 -0700 (PDT) Received: from google.com ([2600:1702:a20:5750::48]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71b264bcc9bsm6607361b3a.79.2024.09.30.12.29.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Sep 2024 12:29:55 -0700 (PDT) Date: Mon, 30 Sep 2024 12:29:53 -0700 From: Noah Misch To: Andres Freund Cc: pgsql-hackers@postgresql.org, Heikki Linnakangas , =?utf-8?B?6ZmI5a6X5b+X?= Subject: Re: AIO v2.0 Message-ID: <20240930192953.19.nmisch@google.com> References: <20240916144349.74.nmisch@google.com> <237y5rabqim2c2v37js53li6i34v2525y2baf32isyexecn4ic@bqmlx5mrnwuf> <20240917180819.e1.nmisch@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.12 (2023-09-09) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Sep 30, 2024 at 10:49:17AM -0400, Andres Freund wrote: > We also discussed the topic at https://postgr.es/m/20240925020022.c5.nmisch%40google.com > > ... neither BM_SETTING_HINTS nor keeping bounce buffers looks like a bad > > decision. From what I've heard so far of the performance effects, if it were > > me, I would keep the bounce buffers. I'd pursue BM_SETTING_HINTS and bounce > > buffer removal as a distinct project after the main AIO capability. Bounce > > buffers have an implementation. They aren't harming other design decisions. > > The AIO project is big, so I'd want to err on the side of not designating > > other projects as its prerequisites. > > Given the issues that modifying pages while in flight causes, not just with PG > level checksums, but also filesystem level checksum, I don't feel like it's a > particularly promising approach. > > However, I think this doesn't have to mean that the BM_SETTING_HINTS stuff has > to be completed before we can move forward with AIO. If I split out the write > portion from the read portion a bit further, the main AIO changes and the > shared-buffer read user can be merged before there's a dependency on the hint > bit stuff being done. > > Does that seem reasonable? Yes.