Re: explain plans with information about (modified) gucs - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: explain plans with information about (modified) gucs
Date
Msg-id 5396e093-ed6b-5962-2ed5-337a0425160b@2ndquadrant.com
Whole thread Raw
In response to Re: explain plans with information about (modified) gucs  (Sergei Agalakov <sergei.agalakov@gmail.com>)
Responses Re: explain plans with information about (modified) gucs  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: explain plans with information about (modified) gucs  (legrand legrand <legrand_legrand@hotmail.com>)
Re: explain plans with information about (modified) gucs  (John Naylor <john.naylor@2ndquadrant.com>)
List pgsql-hackers
Hello Sergei,

> This patch correlates with my proposal
> "add session information column to pg_stat_statements"
> https://www.postgresql.org/message-id/3aa097d7-7c47-187b-5913-db8366cd4491%40gmail.com
> They both address the problem to identify the factors that make
> different execution plans for the same SQL statements. You are
> interested in the current settings that affect the execution plan, I'm
> concerned about historical data in pg_stat_statements. From my
> experience the most often offending settings are
> current_schemas/search_path and current_user. Please have in mind that
> probably the same approach that you will use to extend explain plan
> functionality will be eventually implemented to extend
> pg_stat_statements.

Possibly, although I don't have an ambition to export the GUCs into
pg_stat_statements in this patch. There's an issue with merging
different values of GUCs in different executions of a statement, and
it's unclear how to solve that.

> I think that the list of the GUCs that are reported
> by explain plan should be structured like JSON, something like
> extended_settings: { "current_schemas" : ["pg_catalog", "s1", "s2", "public"],
>       "current_user" : "user1",
>       "enable_nestloop" : "off",
>       "work_mem" = "32MB"
> }
> It is less important for yours use case explain, but is important
> for pg_stat_statements case.
> The pg_stat_statements is often accessed by monitoring and reporting
> tools, and it will be a good idea to have > the data here in the
> structured and easily parsed format.

Yes, that's a good point. I think it's fine to keep the current format
for TEXT output, and use a structured format when the explain format is
set to json or yaml. That's what we do for data about Hash nodes, for
example (see show_hash_info).

So I've done that in the attached v5 of the patch, which now produces
something like this:

test=# explain (gucs, format json) select * from t;
           QUERY PLAN
---------------------------------
 [                              +
   {                            +
     "Plan": {                  +
       "Node Type": "Seq Scan", +
       "Parallel Aware": false, +
       "Relation Name": "t",    +
       "Alias": "t",            +
       "Startup Cost": 0.00,    +
       "Total Cost": 61.00,     +
       "Plan Rows": 2550,       +
       "Plan Width": 4          +
     },                         +
     "GUC": [                   +
       "cpu_tuple_cost": "0.02",+
       "work_mem": "1GB"        +
     ]                          +
   }                            +
 ]
(1 row)

The one slightly annoying issue is that currently all the options are
formatted as text, including e.g. cpu_tuple_cost. That's because the GUC
options may have show hook, so I can't access the value directly (not
sure if there's an option around it).

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Non-deterministic IndexTuple toast compression fromindex_form_tuple() + amcheck false positives
Next
From: Tomas Vondra
Date:
Subject: Re: COPY FROM WHEN condition