Re: On-demand running query plans using auto_explain and signals - Mailing list pgsql-hackers

From Shulgin, Oleksandr
Subject Re: On-demand running query plans using auto_explain and signals
Date
Msg-id CACACo5QHN+04FL9Wg+DW+F+jAN__WqajpTeXaJfq3eEvTgmmgQ@mail.gmail.com
Whole thread Raw
In response to Re: On-demand running query plans using auto_explain and signals  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Sep 29, 2015 at 12:57 PM, Andres Freund <andres@anarazel.de> wrote:
On 2015-09-25 19:13:13 +0200, Shulgin, Oleksandr wrote:
> the auto_explain contrib module.  I now propose the most simple thing
> possible in my opinion: a new GUC option for auto_explain.  It will make
> every backend, in which the module is loaded via *_preload_libraries
> mechanism or using CREATE EXTENSION/LOAD commands, to actively publish the
> plans of queries in dynamic shared memory as long as
> auto_explain.publish_plans is turned on.

Wait. You're proposing that every query does this unconditionally? For
every single query? That sounds prohibitively expensive to me.

Only if the extension is loaded AND the option is turned on.  Likely you don't want to do this for an OLTP database, but for other types of load it might make sense.  Also, I think it should be possible to toggle this on a per-process basis.

Finally, we can put in a cost threshold, so the plans only get published if they have total_cost >= publish_plan_cost_threshod.

Also, do you mean expensive in terms of CPU or the dynamic shared memory?

--
Alex

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Foreign join pushdown vs EvalPlanQual
Next
From: Fujii Masao
Date:
Subject: Re: track_commit_timestamp and COMMIT PREPARED