Re: explain plans with information about (modified) gucs
От | Tomas Vondra |
---|---|
Тема | Re: explain plans with information about (modified) gucs |
Дата | |
Msg-id | 21ebf8ca-d5e4-7c3a-74c5-eaca9d1f1294@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: explain plans with information about (modified) gucs (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: explain plans with information about (modified) gucs
|
Список | 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 по дате отправления: