Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZmipS-0003EU-Fw for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Oct 2015 13:44:22 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZmipS-00072I-26 for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Oct 2015 13:44:22 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1Zmio8-0002ig-6T for pgsql-hackers@postgresql.org; Thu, 15 Oct 2015 13:43:00 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1Zmio5-0006l3-GU for pgsql-hackers@postgresql.org; Thu, 15 Oct 2015 13:42:59 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id t9FDgl83032604; Thu, 15 Oct 2015 09:42:47 -0400 From: Tom Lane To: "Shulgin, Oleksandr" cc: Simon Riggs , Robert Haas , Pavel Stehule , Tomas Vondra , PostgreSQL Hackers Subject: Re: On-demand running query plans using auto_explain and signals In-reply-to: References: <55F3F56C.4000604@2ndquadrant.com> <55F698FE.70605@2ndquadrant.com> <55F6B95E.40! 80507@2ndquadrant.com> ! Comments: In-reply-to "Shulgin, Oleksandr" message dated "Thu, 15 Oct 2015 11:16:01 +0200" Date: Thu, 15 Oct 2015 09:42:47 -0400 Message-ID: <32603.1444916567@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org "Shulgin, Oleksandr" writes: > I was thinking about this and what seems to be the biggest problem is when > to actually turn the feature on. It seems unlikely that someone will want > to enable it unconditionally. Enabling per-backend also doesn't seem to be > a good approach because you don't know if the next query you'd like to look > at is going to run in this exact backend. Check. > What might be actually usable is poking pg_stat_statements for queryid to > decide if we need to do explain (and possibly analyze). Hm, interesting thought. > Does this make sense to you? Does this make a good argument for merging > pg_stat_statements and auto_explain into core? I'd say more that it's a good argument for moving this feature out to one of those extensions, or perhaps building a third extension that depends on both of those. TBH, none of this stuff smells to me like something that ought to be in core. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers