From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Sergei Agalakov <sergei(dot)agalakov(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: explain plans with information about (modified) gucs |
Date: | 2019-02-14 19:55:01 |
Message-ID: | 20190214195501.dplga6fadovwlm6d@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-01-15 02:39:49 +0100, Tomas Vondra wrote:
>
>
> On 1/14/19 11:13 PM, Alvaro Herrera wrote:
> > On 2019-Jan-14, Tomas Vondra wrote:
> >
> >> 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).
> >
> > I think the problem is that you'd have to know how to print the value,
> > which can be in one of several different C types. You'd have to grow
> > some more infrastructure in the GUC tables, I think, and that doesn't
> > seem worth the trouble. Printing as text seems enough.
> >
>
> I don't think the number of formats is such a big issue - the range of
> formats is quite limited: PGC_BOOL, PGC_INT, PGC_REAL, PGC_STRING and
> PGC_ENUM. But the show hook simply returns string, and I'm not sure it's
> guaranteed it matches the raw value (afaik the assign/show hooks can do
> all kinds of funny stuff).
Yea, but the underlying values are quite useless for
humans. E.g. counting shared_buffers, wal_buffers etc in weird units is
not helpful. So you'd need to support the different units for each.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-02-14 20:01:48 | Re: shared-memory based stats collector |
Previous Message | Oleksii Kliukin | 2019-02-14 19:46:38 | Re: Per-tablespace autovacuum settings |