út 1. 1. 2019 v 18:39 odesílatel Tomas Vondra <tomas.von...@2ndquadrant.com>
napsal:
> Attached is v4, changing how GUCs are picked for inclusion on the query
> plans. Instead of picking the GUCs based on group and/or explicitly, a
> new GUC_EXPLAIN flag is used for that.
>
> I went through GUCs defined in guc.c and marked those in QUERY_TUNING*
> groups accordingly, with the exception of default_statistics_target
> because that seems somewhat useless without showing the value used to
> actually analyze the table (and/or columns).
>
> I've also included a couple of other GUCs, that I find to be relevant:
>
> - parallel_leader_participation
> - max_parallel_workers_per_gather
> - max_parallel_workers
> - search_path
> - effective_io_concurrency
> - work_mem
> - temp_buffers
> - plan_cache_mode
>
when plan_cache_mode is auto, you know maybe too less executed query. Maybe
you can read somewhere if plan was custom or generic.
> I think this covers the interesting GUCs pretty well, although perhaps I
> missed something.
>
seq_page_cost, random_page_cost, from_collapse_limit, join_collapse_limit,
... enable_***
> The one bit that needs fixing is escaping the GUC values when showing
> them in the plan. Looking at the other places that currently escape
> stuff, I see they only care about YAML/JSON/XML and leave the regular
> output unescaped. I was wondering if it's OK with the current format
> with all GUCs on a single line
>
> QUERY PLAN
> ---------------------------------------------------
> Seq Scan on t (cost=0.00..54.63 rows=13 width=4)
> Filter: ('x''y'::text = (a)::text)
> GUCs: enable_nestloop = 'off', work_mem = '32MB'
> (3 rows)
>
> but I suppose it is, because without the escaping a user can break
> whatever format we use. So I'll do the same thing, escaping just the
> structured formats (YAML et al).
>
> The question however is whether someone has a better formatting idea?
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
