On Thursday, May 19, 2016, David Christensen <
david@endpoint.com> wrote:
> On May 19, 2016, at 3:17 PM, Евгений Шишкин <itparanoia@gmail.com> wrote:
>
>
>> On 19 May 2016, at 22:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> David Christensen <david@endpoint.com> writes:
>>> This simple patch adds “ALL” as an EXPLAIN option as shorthand for “EXPLAIN (ANALYZE, VERBOSE, COSTS, TIMING, BUFFERS)” for usability.
>>
>> I'm not sure this is well thought out. It would mean for example that
>> we could never implement EXPLAIN options that are mutually exclusive
>> ... at least, not without having to redefine ALL as all-except-something.
>> Non-boolean options would be problematic as well.
>>
>
> Maybe EVERYTHING would be ok.
> But it is kinda long word to type.
If it’s just a terminology issue, what about EXPLAIN (*); already a precedent with SELECT * to mean “everything”. (MAX?
LIKE_I’M_5?) Let the bikeshedding begin!
+1
In any case, I think a shorthand for “give me the most possible detail without me having to lookup/type/remember the options” is a good tool.
EXPLAIN THIS
EXPLAIN BETTER
EXPAIN ABCTV (might need permission to document this variation though)
The later has some resemblance to option short form in command lines.
The bigger question is do we want to solve this in the server or let it be a client concern and stick some usability enhancements into psql? Maybe even put it in psql first then migrate to the server after some field experience.
The middle road is probably something like the following:
We could setup a guc for "default_explain_options" that the user could set or have set for them using alter role. Maybe we'd want to include a new option "CLEAN" or "NONE" that tells the system to skip those default and only use ones that are explicitly specified in the SQL command. Basically an envvar like many command line apps use in lieu of an .rc file but with a simpler way to disable than setting it to nothing.