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 1gs6EC-0005wS-C1 for pgsql-general@arkaria.postgresql.org; Fri, 08 Feb 2019 13:30:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gs6EB-0005h8-3a for pgsql-general@arkaria.postgresql.org; Fri, 08 Feb 2019 13:29:59 +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 1gs6EA-0005gy-Nj for pgsql-general@lists.postgresql.org; Fri, 08 Feb 2019 13:29:58 +0000 Received: from mail-it1-x141.google.com ([2607:f8b0:4864:20::141]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gs6E8-0000dH-3W for pgsql-general@postgresql.org; Fri, 08 Feb 2019 13:29:57 +0000 Received: by mail-it1-x141.google.com with SMTP id c9so8832908itj.1 for ; Fri, 08 Feb 2019 05:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :user-agent; bh=qj7dQbV/iIMAztslacCEJvkpGy2SsYfbYeHbujzFdpY=; b=ujtEJO4BFS4FgNbrw3EoscRFwHlB6i2kfoxPcqAUOCOIBsSS++6XTGRu5VFJI0Asv/ +CRyC+MLvjmXXqM4DSLrj02APtGY7jepMaMPcaJHbOUIlkw4wv+HYhooYyHpZVdpxc+u Es4mIYlkXQLnbhiEG9ndm34tX+PbjIEG/vxhDj16VtBFk+Dl8Ijwi2dPeAY7vSWJO28O jRH9sI9FIGhK0ZY+PASX6MRo17DQS3fnRHbYo/ou19Fb7V/tr1D/2JnaNpHdA/c1ASNO YCfWK1PtVdhyK8evHOe+XlPUEgPf5wjWPn96FLBB6ruVoiIpTV6QQ813W6ue/u7XI2H0 IM+Q== 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:mime-version :content-disposition:user-agent; bh=qj7dQbV/iIMAztslacCEJvkpGy2SsYfbYeHbujzFdpY=; b=rA2mf9MmhVZfmfBVRUvqKIzRP2XKJv9k4lwckLGQl1PoY004UAmCNHLjEgYzB5C5Fs R6ZEVscjXN1PmtD/hU1QElWiP4kBevyHYKir1MrmdSHkZqUcntb1VanANoqapk9Aq50z R6fXdF57foiakG4m2tO0KGamPJVVc3br0/XwThFETcGsNsvc0OL/jliaEzpfu7Bz73Fj /xF4/iZbdlpwa9roBLp4eCwvXA4L94nVcEHu1wjNAy7Mqvy7fjtc4AkdnHXEEinUqK2o wxeNXIzlOR4qbt7+TxBcP2XmwvQVJpDfh6WynPsMaWXmAHfwXylRu/Pv2FkBHiNKNc/p +f3A== X-Gm-Message-State: AHQUAuYSVlP4jcyqilUPIvXXdHfEtzdCx/gim47HJquydpr02krIqGjP DtT0z1NfnAgNpLRmvjboshjTmUwcGK4= X-Google-Smtp-Source: AHgI3IY0nGe/5IitB1jh7Q/E3aw9FvlNT6fFsIVFBUn14TIY7kmLuBsk3AeJ9ZPBj8ox/FWnFrOAQQ== X-Received: by 2002:a05:660c:84e:: with SMTP id f14mr7611829itl.33.1549632594882; Fri, 08 Feb 2019 05:29:54 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id x99sm1196762ita.23.2019.02.08.05.29.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 05:29:54 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id 5BC1A800BD7; Fri, 8 Feb 2019 07:29:53 -0600 (CST) Date: Fri, 8 Feb 2019 07:29:53 -0600 From: Justin Pryzby To: pgsql-general@postgresql.org Cc: Bruce Momjian Subject: query logging of prepared statements Message-ID: <20190208132953.GF29720@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk A couple months ago, I implemented prepared statements for PyGreSQL. While updating our application in advance of their release with that feature, I noticed that our query logs were several times larger. With non-prepared statements, we logged to CSV: |message | SELECT 1 With SQL EXECUTE, we log: |message | statement: EXECUTE sqlex(2); |detail | prepare: prepare sqlex AS SELECT $1; With PQexecPrepared, we would log: |message | execute qq: PREPARE qq AS SELECT $1 |detail | parameters: $1 = '3' For comparison, with PQexecParams, the logs I see look like this (apparently the "unnamed" prepared statement is used behind the scenes): |message | execute : SELECT [...] It's not clear to me why it'd be desirable for the previous PREPARE to be additionally logged during every execution, instead of just its name (in "message") and params (in "detail"). (Actually, I had to triple check that it wasn't somehow executing a prepared statement which itself created a prepared statement...) For us, the performance benefit is to minimize the overhead (mostly in pygres) of many INSERTs into append-only tables. It's not great that a feature intended to improve performance is causing 2x more log volume to be written. Also, it seems odd that for SQL EXECUTE, the PREPARE is shown in "detail", but for the library call, it's shown in "message". I found: |commit bc24d5b97673c365f19be21f83acca3c184cf1a7 |Author: Bruce Momjian |Date: Tue Aug 29 02:11:30 2006 +0000 | | Now bind displays prepare as detail, and execute displays prepare and | optionally bind. I re-added the "statement:" label so people will | understand why the line is being printed (it is log_*statement | behavior). | | Use single quotes for bind values, instead of double quotes, and double | literal single quotes in bind values (and document that). I also made | use of the DETAIL line to have much cleaner output. and: |commit c8961bf1ce0b51019db31c5572dac18b664e02f1 |Author: Bruce Momjian |Date: Fri Aug 4 18:53:46 2006 +0000 | | Improve logging of protocol-level prepared statements. Justin