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 1kPxn5-0003v3-Is for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Oct 2020 00:58:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kPxn4-0001gj-GW for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Oct 2020 00:58:46 +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 1kPxn4-0001gc-4E for pgsql-hackers@lists.postgresql.org; Wed, 07 Oct 2020 00:58:46 +0000 Received: from mail-ed1-x541.google.com ([2a00:1450:4864:20::541]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kPxn1-0004Mx-Gn for pgsql-hackers@postgresql.org; Wed, 07 Oct 2020 00:58:44 +0000 Received: by mail-ed1-x541.google.com with SMTP id g4so410132edk.0 for ; Tue, 06 Oct 2020 17:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=22fiC0B3DJXpGnCfmI6/OUE/QRR45TOj53nURXksgvY=; b=xU021peY08Ik1PJ6I6VI2mLGJ7aX22tZLC3B7k9lYMNRdI21vvsLNZ3PBE04jEvODT Oc09TirJutIMYPbW2XjS8ARWjQ7XTHMUwo3MHflSXXm/tZX4s/ly57L+rI64f3H7rSQY rSsBo/r4zroYuOJ8cHo7BQ2Vkgp0IVwzlZPID6Io4FwmymO6yyjV6WE68svIFUf+yPPf W1pnR7K88z57+X1fxQxfWgDXaOHLuXXntLPtbi/ZQslbQqUpgm6gRFJyhsrJmQJIWdN2 fh/qGWF/azWYfmwlVHb9ies6r+IrbFG9iT8CVEkf+FwaGzbSok3EcaFAgGkwDC5EwUmP d79A== 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; bh=22fiC0B3DJXpGnCfmI6/OUE/QRR45TOj53nURXksgvY=; b=YKRdHPKzQ+YqUKWxUYoyqRJu+yidwK+bQ51keu55TNWOf0xi2fTs/yirRTS5fJM3Px Own9gb3/yH+52DxDnpVDRL03nddTHVf8zHuOKnKDuaUno6U+fo/xq/XQQJma9g/xgBI7 eJqjPYBDc/8hLRW5cGcgVm/eCvexXNCK+q6gxyQeJ6ThBO5iXAL+MbfQDlYJv2mYwmZM L2LTkyeONvCj6MtUy5hPPTVJMo+Q8sA6lvSjuzAzfDQA8+OWkBHTj0nYYLQKUACt37xp gOwyFots2bDQ9kI0MWbcMUSrmuWc6NS/ngJTP9W+TCZh6PAUG7k24MNzSFfbctGZnI0u 2A3Q== X-Gm-Message-State: AOAM531fN5+c6ektHVantmblsUEoztjrCPJJIBs1na90bM/qUA2cccfl 3x5dj3SwfODfG82XZ1osoD472Lks2hE5imPA X-Google-Smtp-Source: ABdhPJwLcWOlUnybIoyHMSdSVj/a9qru5n5W0SjLMJ4Vs6s3BM3uX30XmI5U+xOMU4NTGxi9DB9ESQ== X-Received: by 2002:aa7:cb8f:: with SMTP id r15mr895637edt.356.1602032321166; Tue, 06 Oct 2020 17:58:41 -0700 (PDT) Received: from localhost (ip-86-49-245-76.net.upcbroadband.cz. [86.49.245.76]) by smtp.gmail.com with ESMTPSA id e4sm254752edk.38.2020.10.06.17.58.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Oct 2020 17:58:40 -0700 (PDT) Date: Wed, 7 Oct 2020 02:58:38 +0200 From: Tomas Vondra To: Thomas Munro Cc: Stephen Frost , Dmitry Dolgov <9erthalion6@gmail.com>, David Steele , Andres Freund , Alvaro Herrera , pgsql-hackers Subject: Re: WIP: WAL prefetch (another approach) Message-ID: <20201007005838.lrpsbpckc5b7giwk@development> References: <20200803154659.nzf5qzuozts5dujp@development> <20200806104701.j3xnkczd6qelfnhj@development> <20200901131426.5lse2jlepm3uligv@development> <20200901141826.gbhqz664brtt4y2t@development> <20200908231235.lsgat5ni35h6odqt@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Sep 24, 2020 at 11:38:45AM +1200, Thomas Munro wrote: >On Wed, Sep 9, 2020 at 11:16 AM Tomas Vondra > wrote: >> OK, thanks for looking into this. I guess I'll wait for an updated patch >> before testing this further. The storage has limited capacity so I'd >> have to either reduce the amount of data/WAL or juggle with the WAL >> segments somehow. Doesn't seem worth it. > >Here's a new WIP version that works for archive-based recovery in my tests. > >The main change I have been working on is that there is now just a >single XLogReaderState, so no more double-reading and double-decoding >of the WAL. It provides XLogReadRecord(), as before, but now you can >also read further ahead with XLogReadAhead(). The user interface is >much like before, except that the GUCs changed a bit. They are now: > > recovery_prefetch=on > recovery_prefetch_fpw=off > wal_decode_buffer_size=256kB > maintenance_io_concurrency=10 > >I recommend setting maintenance_io_concurrency and >wal_decode_buffer_size much higher than those defaults. > I think you've left the original GUC (replaced by the buffer size) in the postgresql.conf.sample file. Confused me for a bit ;-) I've done a bit of testing and so far it seems to work with WAL archive, so I'll do more testing and benchmarking over the next couple days. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services