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.89) (envelope-from ) id 1huNR7-0003wK-Ow for pgsql-hackers@arkaria.postgresql.org; Sun, 04 Aug 2019 20:49:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1huNR5-00026N-Ok for pgsql-hackers@arkaria.postgresql.org; Sun, 04 Aug 2019 20:48:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1huNR5-00025J-BP for pgsql-hackers@lists.postgresql.org; Sun, 04 Aug 2019 20:48:59 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1huNQx-0005C7-Uu for pgsql-hackers@lists.postgresql.org; Sun, 04 Aug 2019 20:48:58 +0000 Received: by mail-wr1-x443.google.com with SMTP id g17so82351742wrr.5 for ; Sun, 04 Aug 2019 13:48:51 -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:user-agent; bh=FwGf1lGdNjt1KKqlF0qEpNgvfw+chEgZojnDpn9ySLQ=; b=DCKQlIK232J/HADCqFjkN6C1LG6DR8IaNVnbKU7UqaO97DIaGdht98sWzYCjRfzcFX 0XqUOvCvqQhKW/8bsa6Ajcu7DflliLw3hCASu1QCsh643wnyP5HteJbLWvTNk5gDWupz TIz+9bW/OEp1Ep+ysySZZulotjDtTHqTodIzrhGH8Fu6+h0HiLi88AmtD8DehG+Rb8Zx nxjVMtNhqOU/SO1ojHjam99K2Kra3MPdY5jGy295a+LWRAd/FQLUNHigkUM1TrwnCy5u SU7M2S499XK1daN+zdTM6vV0Efze5ArRcOryMX4k5IZozwhBQx/42pWRN4QWMwPdg31i 5JNQ== 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:user-agent; bh=FwGf1lGdNjt1KKqlF0qEpNgvfw+chEgZojnDpn9ySLQ=; b=FqUTqbH7kWixAsrspZhLsCIaabTRP/jR/R6SkDQMf3p/J12Bovzj9tOTqQUudmzioF trF00LnIkjFhBHU6MZnGQlTsH3LzyuRdTNxT9YZn09w+oeVzF5dbK+H9btrD0WWhtILU bG630EC9sUDmPaXF29DRHHZIUxZpzBXnYBu+G8bfwK9+8OY02E4hy/LsAXZ2R1kmlI26 jyWyDWgEAOoyE51DEEMGITmTFlkWncMs0HsYtmMw/WVQKGUEUXKdOy/lCZ3ALLCdkp+D DDLdUUfnXMqBPp5J66j9oQlCI0zyJt9n1NovNQXErtecbWTn7S7W/xwx/xrA8exYtTOm sOKg== X-Gm-Message-State: APjAAAVy5DRbywUJCB/8wvbhXWCqYwXfda29hvPndGAx2be7RD2Y/CFm g7Rrg8izYN9OlWoBWScsmvQg2w== X-Google-Smtp-Source: APXvYqw610oOHt8RypTcMIs5v44zsVkTvN3OI84fU1Lwb/S2VdyVo1y1/37rZyCS1hjf+C5wJ8auig== X-Received: by 2002:adf:ec0c:: with SMTP id x12mr21806774wrn.342.1564951730606; Sun, 04 Aug 2019 13:48:50 -0700 (PDT) Received: from localhost (ip-86-49-253-160.net.upcbroadband.cz. [86.49.253.160]) by smtp.gmail.com with ESMTPSA id v16sm75599356wrn.28.2019.08.04.13.48.49 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Sun, 04 Aug 2019 13:48:49 -0700 (PDT) Date: Sun, 4 Aug 2019 22:48:48 +0200 From: Tomas Vondra To: Tom Lane Cc: Adrien Nayrat , pgsql-hackers@lists.postgresql.org Subject: Re: idea: log_statement_sample_rate - bottom limit for sampling Message-ID: <20190804204848.7f7ypsbijpgxojxx@development> References: <20190727221948.irg6sfqh57dynoc7@development> <4540bafe-1b23-a6ce-a313-f3b03bb418df@anayrat.info> <20190801100445.yo5v3pdxelijztzm@development> <3f6b75ea-03bb-7c35-1f20-e989f4b7f9ac@anayrat.info> <20190804191037.em6rmlvxjpcsjtqu@development> <25079.1564946172@sss.pgh.pa.us> <20190804195823.qi7vntgybfgitdnn@development> <27954.1564950312@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <27954.1564950312@sss.pgh.pa.us> User-Agent: NeoMutt/20180716-1444-295967 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Aug 04, 2019 at 04:25:12PM -0400, Tom Lane wrote: >Tomas Vondra writes: >> On Sun, Aug 04, 2019 at 03:16:12PM -0400, Tom Lane wrote: >>> Isn't the issue here the interaction between log_transaction_sample_rate >>> and log_min_duration_statement? > >> No, that interaction only affects statement-level sampling. > >OK, I was confusing the features. > >> For transaction-level sampling we do the sampling independently of the >> statement duration, i.e. we when starting a transaction we determine >> whether the whole transaction will be sampled. It has nothing to do with >> the proposed log_statement_sample_limit. > >So, to clarify: our plan is that a given statement will be logged >if any of these various partial-logging features says to do so? > Yes, I think that's the expected behavior. - did it exceed log_min_duration_statement? -> log it - is it part of sampled xact? -> log it - maybe sample the statement (to be reverted / reimplemented) >(And the knock on HEAD's behavior is exactly that it breaks that >independence for log_min_duration_statement.) > Yeah. There's no way to use sampling, while ensure logging of all queries longer than some limit. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services