Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jIBfZ-0001IF-Ed for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Mar 2020 13:38:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jIBfY-0005oF-7z for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Mar 2020 13:38:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jIBfX-0005o7-Rc for pgsql-hackers@lists.postgresql.org; Sat, 28 Mar 2020 13:38:35 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jIBfV-0001DX-NQ for pgsql-hackers@postgresql.org; Sat, 28 Mar 2020 13:38:34 +0000 Received: by mail-lj1-x235.google.com with SMTP id g27so13021790ljn.10 for ; Sat, 28 Mar 2020 06:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=0kDwphvKA95y1Wo47ff54HrJh7EPahpuKLVjgwf8Ujc=; b=ON1B180E1xaqzN4j//HeHGLKQDYv/VyNJpeIg191mVLqL10bA2Qs+Wt/9vj0vmQbK4 0yUtXrwxUhiKSJCMGQ6zAZuBCw5px7JoCqNrPGbdBw74QN1i1wAaAAoXSNam7BfAs0No +k2RxAV0GTJ9DTDmwb/Bmdc0AhvCW3379S2KWgRlAA/xI3MtsRm0gvzlO0tf7wqPOyig o/zk50zWGdcq005CzhPCdgjBK4M4eCf8QGjmGU7ytQKIolmu5agWgBjdC4i4sXiune6i 9rTKKD7e4I7j1areM99DqKlMfYYCL3JEccb3SM1yKOQPwsCHUqLQTgBhUu1caqhrUWjt kT9Q== 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=0kDwphvKA95y1Wo47ff54HrJh7EPahpuKLVjgwf8Ujc=; b=HxZrlpZm8r/7x8Lk3Vm0lx4xzUNyj3SvDpkk/tNWjUdRVebHTu9LxwfvcKn8rhS7xX cpqtiHF5OISuvN/BMOqqrOTLjeBDAWbJ0ajc4Y6+I4X0qrOL2y+QJLSn94U87CREvGMJ 2QFcVtD8V1E/20BnTXnlfrmGJfi+NSk52appSUDQPFYE9H9xcAOQ88QfD8fY7/Aw5Wls kaM78KqMTGypxueKX22wefssyxmZqeIN4YhBL3L9KmQJ0+0UFNMLZhq2c7sKpRDiIC3x qEo24mLQg+Goa/7fUK7AKXOyrE5gZNkmrno5swakJc4jPiZJQU7PkTetR+FGCrOXyQ06 8XyQ== X-Gm-Message-State: AGi0PuaXgBbYuz7vM2UQRWmY27F79LHNbVQp7tUqE7Smg2j6ivovZCcQ cAZep1Rx8xlS/6he3CJB8iE= X-Google-Smtp-Source: APiQypIqhsp8mifpl6iux8E8luyStyLkjx0bnsUc/THZ21BIEQ8AxGi40YddsOeBPyQ28+ssXMgcWg== X-Received: by 2002:a2e:8e83:: with SMTP id z3mr2265282ljk.239.1585402711918; Sat, 28 Mar 2020 06:38:31 -0700 (PDT) Received: from nol (82-64-124-11.subs.proxad.net. [82.64.124.11]) by smtp.gmail.com with ESMTPSA id x78sm4366850lfa.51.2020.03.28.06.38.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Mar 2020 06:38:31 -0700 (PDT) Date: Sat, 28 Mar 2020 14:38:27 +0100 From: Julien Rouhaud To: Amit Kapila Cc: Kirill Bychik , PostgreSQL Hackers , Fujii Masao , Thomas Munro Subject: Re: WAL usage calculation patch Message-ID: <20200328133827.GA12854@nol> References: <20200318171916.GA69354@nol> <5b71ad52-68c6-08cb-6408-31307e9e6f10@oss.nttdata.com> <20200319153129.GA36079@nol> <762d4ee8-9710-cdcd-e661-b5c79aaa9bf0@oss.nttdata.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sat, Mar 28, 2020 at 04:14:04PM +0530, Amit Kapila wrote: > > I see some basic problems with the patch. The way it tries to compute > WAL usage for parallel stuff doesn't seem right to me. Can you share > or point me to any test done where we have computed WAL for parallel > operations like Parallel Vacuum or Parallel Create Index? Ah, that's indeed a good point and AFAICT WAL records from parallel utility workers won't be accounted for. That being said, I think that an argument could be made that proper infrastructure should have been added in the original parallel utility patches, as pg_stat_statement is already broken wrt. buffer usage in parallel utility, unless I'm missing something. > Basically, > I don't know changes done in ExecInitParallelPlan and friends allow us > to compute WAL for parallel operations. Those will primarily cover > parallel queries that won't write WAL. How you have tested those > changes? I didn't tested those, and I'm not even sure how to properly and reliably test that. Do you have any advice on how to achieve that? However the patch is mimicking the buffer instrumentation that already exists, and the approach also looks correct to me. Do you have a reason to believe that the approach that works for buffer usage wouldn't work for WAL records? (I of course agree that this should be tested anyway)