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 1k2cg9-000127-V6 for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Aug 2020 15:47:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k2cg8-0002ba-F1 for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Aug 2020 15:47:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k2cg8-0002bT-81 for pgsql-hackers@lists.postgresql.org; Mon, 03 Aug 2020 15:47:08 +0000 Received: from mail-ej1-x641.google.com ([2a00:1450:4864:20::641]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k2cg5-0004Uw-Bm for pgsql-hackers@postgresql.org; Mon, 03 Aug 2020 15:47:07 +0000 Received: by mail-ej1-x641.google.com with SMTP id qc22so24330892ejb.4 for ; Mon, 03 Aug 2020 08:47:04 -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=Ud3D/P9IL50cSjthRNgX+CT7FfEOsL9ACVtW2/RE2b4=; b=akf4QQD3HC4AUq93bNJeQICbkAsLeUnQ0IPGC1Hy4E6UReqXLJO8xIRj/Vc6a+9INw 5kFDdmYHBr3Jys7MOOtj2+8ui8BAG0YyxhRY8YmqufWAMrdrqqbkyYNKvZbdA1XNXqWC YJib7OWBe+FCbaNlnt5XoRG9YCKi/qOZmBnZwWNeXVjCE0saLbGKJb9oWXurkkyJ2SGe qKLrHIPxexfaAVcP1VGppdhykLL3FPef+GG2g6DcT9xPjuKD43WgtN61+TiJTfyO/wmc czVsE3yP3wv6pyq+k/McV+q4tnaQLhGo6UCAa16lzocxKcbpgTrCGKQrKYwF7pBJspy8 ecuw== 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=Ud3D/P9IL50cSjthRNgX+CT7FfEOsL9ACVtW2/RE2b4=; b=Hob9Iq+ACokLElnztZUm8Be4M4sPAF+jAcxSk58MQaZbBfmhJ2gIwANvGlpYyrssS7 J25GPEl4m+xC+MUc1d9IX88ypXkTQ48Ij23QldS0BrImxwvKpQ9iUxRN5rnvZu9XRPcH 5plponoP0U/9ecK0DBHlUG+WJSuG7e/Cj6r8G2Yj8NcHP6W5/MMvNzpACXAbYcWDNDn7 bkUY3Pr3Us1mvS37zeWlWzCuK2GMy+UveP1a/gt2MFTkO3LG/yD/kiB2i7dT1X9by6tx rQyOKue7a/1pvHfyBMaboV9KcIUp1kNy7lJU4VGlsY5Mknw154R3L6ZEOpbkPwurXR9u HHvw== X-Gm-Message-State: AOAM531TjeLspUm3DZPdVWuH6hbbKO1iGEInSwIVPfKIJrYcxfDDY+pH Y9B5/VojTPFlFE5vBDxAp5Ze0w== X-Google-Smtp-Source: ABdhPJwI68c67BPMKfi3ntbwvX64cvN6IkVEciZbus33iciBJPVKYKGQjlZ5MFDGdabTj8F2k+pHrA== X-Received: by 2002:a17:906:a242:: with SMTP id bi2mr16833044ejb.243.1596469624126; Mon, 03 Aug 2020 08:47:04 -0700 (PDT) Received: from localhost (ip-86-49-253-141.net.upcbroadband.cz. [86.49.253.141]) by smtp.gmail.com with ESMTPSA id a16sm16080420ejy.78.2020.08.03.08.47.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2020 08:47:01 -0700 (PDT) Date: Mon, 3 Aug 2020 17:46:59 +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: <20200803154659.nzf5qzuozts5dujp@development> References: <226b5950-7404-a51d-8dc7-53895b363a38@pgmasters.net> <20200419114820.h62ryte7uwu46e2x@localhost> <20200425191935.4p6qxzzu5bklodwk@localhost> <20200502151423.yf52i63u232fdfrg@localhost> <20200605223422.r76a5rpl2zg2xo34@development> <20200606003632.GS6680@tamriel.snowman.net> 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, Jul 02, 2020 at 03:09:29PM +1200, Thomas Munro wrote: >On Sat, Jun 6, 2020 at 12:36 PM Stephen Frost wrote: >> * Tomas Vondra (tomas.vondra@2ndquadrant.com) wrote: >> > I wonder if we can collect some stats to measure how effective the >> > prefetching actually is. Ultimately we want something like cache hit >> > ratio, but we're only preloading into page cache, so we can't easily >> > measure that. Perhaps we could measure I/O timings in redo, though? >> >> That would certainly be interesting, particularly as this optimization >> seems likely to be useful on some platforms (eg, zfs, where the >> filesystem block size is larger than ours..) and less on others >> (traditional systems which have a smaller block size). > >I know one way to get information about cache hit ratios without the >page cache fuzz factor: if you combine this patch with Andres's >still-in-development AIO prototype and tell it to use direct IO, you >get the undiluted truth about hits and misses by looking at the >"prefetch" and "skip_hit" columns of the stats view. I'm hoping to >have a bit more to say about how this patch works as a client of that >new magic soon, but I also don't want to make this dependent on that >(it's mostly orthogonal, apart from the "how deep is the queue" part >which will improve with better information). > >FYI I am still trying to reproduce and understand the problem Tomas >reported; more soon. Any luck trying to reproduce thigs? Should I try again and collect some additional debug info? regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services