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 21ebf8ca-d5e4-7c3a-74c5-eaca9d1f1294@2ndquadrant.com
Whole thread Raw
In response to Re: explain plans with information about (modified) gucs  (Andres Freund <andres@anarazel.de>)
Responses Re: explain plans with information about (modified) gucs
List pgsql-hackers

On 2/14/19 8:55 PM, Andres Freund wrote:
> 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.
> 

True. So you agree printing the values as text (as the patch currently
does) seems enough? I guess I'm fine with that.

regards

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


pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Protect syscache from bloating with negative cache entries
Next
From: Tom Lane
Date:
Subject: Re: Reporting script runtimes in pg_regress