generic options for explain

Поиск
Список
Период
Сортировка
От Robert Haas
Тема generic options for explain
Дата
Msg-id 603c8f070905231747j2e099c23hef8eafbf26682e5f@mail.gmail.com
обсуждение исходный текст
Ответы Re: generic options for explain  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: generic options for explain  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Well, here we are!  Yet another thread about some piece of information
that's omitted from EXPLAIN and can't easily be added because there
are a zillion things we want to add to EXPLAIN and it's not OK to bury
the user[1]!  I've long been of the opinion that the right way to fix
this problem is to extend the syntax with some sort of extensible
options syntax[2].  The current "EXPLAIN [ANALYZE] [VERBOSE] <query>"
syntax does not scale to large numbers of options - it requires that
the options occur in a fixed order, and that the option names all be
keywords.  Having gotten throughly fed up with having this
conversation for the ump-teenth time, I wrote a patch to introduce
just such a syntax.  See attached.

What I did is borrowed the generic options stuff that Peter Eisentraut
introduced for FOREIGN DATA WRAPPER et. al, so you can write:

EXPLAIN (option_name1 "option_value1", option_name2 "option_value2") query
e.g. EXPLAIN (ANALYZE "on") query

As written, this patch doesn't introduce any actual new functionality,
but I think it's pretty easy to see how we could build on the syntax
to add things like different types of output formats, different types
of instrumentation, etc.  A few other random notes:

- This currently lacks documentation.  If we have any consensus that
this is a reasonable approach, I'll add some.
- I noticed that we currently accept as a top-level SQL command an
arbitrarily parenthesized SELECT statement, like ((SELECT 3)).  But
you can't put parentheses around any other type of statement.  Even
more oddly, we also accept things like (SELECT 3) ORDER BY 1, which to
me makes no sense at all.  But that's neither here nor there as far as
this patch is concerned, except that it required some minor grammar
hackery and a long comment explaining the hackery.

Thoughts?

...Robert

[1] http://archives.postgresql.org/message-id/4A16A8AF.2080508@anarazel.de
[2] http://archives.postgresql.org/message-id/603c8f070904151758w6af25641xac831b4cb71c4184@mail.gmail.com

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Konstantin Izmailov
Дата:
Сообщение: Re: information_schema.columns changes needed for OLEDB
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: information_schema.columns changes needed for OLEDB