Subject: Re: On-demand running query plans using auto_explain and
 signals
To: Pavel Stehule <pavel.stehule@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
References: 
 <CACACo5Sz7G0MFauC082iM=XX_hQ7qQ5ndR4JPo+H-O5vp6iCcQ@mail.gmail.com>
 <CAFj8pRAB4otjEtv2eEkEyX1YCmDg+5JCEH0GeabKosjopN52Cw@mail.gmail.com>
 <CA+TgmoYjkGXvywwm9qoODkU1UJZweshDdCUREd-rsvab75oecQ@mail.gmail.com>
 <CACACo5Q=nEEzAUE3o29WTU0wW7wourZB+SDhwPYzGZPyggF4hg@mail.gmail.com>
 <CAFj8pRAENjXoLQp+_nRZXuqzn7kJRx7YUScD6O=yczmi1CU3qQ@mail.gmail.com>
 <CACACo5QSG0yy9dD_Ots8Zy+djvSOrfwfmU-wC+y8HPgo4tzoqg@mail.gmail.com>
 <CAFj8pRBayKwzi1oiyW1PXfyZeb_HdKRmuHn909-7i7Ao1zXBdw@mail.gmail.com>
 <CA+TgmoYax0YVp5RGpAStyfHanNbRcTWXrOzci34+dbpJTvkCvw@mail.gmail.com>
 <CACACo5StM7ikEEJi64B49k_zpUMXWVhdDKKyiHBS5tv+5S4VfA@mail.gmail.com>
 <CANP8+jJQA4OYCMu-FQeV-zXPFGQN0CUZBXq+cVEC_Pm32vw-1g@mail.gmail.com>
 <CACACo5ReQKEzKyGCsEMYr9v23qsP=tStaFsstTK8G7_vXsWbxA@mail.gmail.com>
 <CACACo5R8J=+btDzS4+KQsAE5QGiZFhushdJL8BPc_63nrySyLQ@mail.gmail.com>
 <32603.1444916567@sss.pgh.pa.us>
 <CAFj8pRBhdv6N4yRfJBd-JjYnfM89c4nshJEDyzxGVTWOCwy6vw@mail.gmail.com>
Cc: "Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>,
 Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
From: Julien Rouhaud <julien.rouhaud@dalibo.com>
Message-ID: <565CBF3C.7080106@dalibo.com>
Date: Mon, 30 Nov 2015 22:27:24 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
 <CAFj8pRBhdv6N4yRfJBd-JjYnfM89c4nshJEDyzxGVTWOCwy6vw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Hello,

On 15/10/2015 16:04, Pavel Stehule wrote:
> 
> 
> 2015-10-15 15:42 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us
> <mailto:tgl@sss.pgh.pa.us>>:
> 
>     "Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de
>     <mailto:oleksandr.shulgin@zalando.de>> 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.
> 
> 
> There are few features, that I would to see in core:
> 
> 1. possibility to get full SQL string
> 2. possibility to get state string
> 
> We can speak how to do it well.
> 

I registered as reviewer on this, but after reading the whole thread for
the second time, it's still not clear to me if the last two submitted
patches (0001-Add-auto_explain.publish_plans.patch and
0002-Add-SHM-table-of-contents-to-the-explain-DSM.patch) are still
needed reviews, since multiple refactoring ideas and objections have
been raised since.


Regards.

-- 
Julien Rouhaud
http://dalibo.com - http://dalibo.org


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers