Re: machine-readable explain output

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: machine-readable explain output
Дата
Msg-id 603c8f070906150501g622045ddl33d7a93b793a490e@mail.gmail.com
обсуждение исходный текст
Ответ на Re: machine-readable explain output  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: machine-readable explain output  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
I wrote:
> On Sun, Jun 14, 2009 at 1:04 PM, Robert Haas<robertmhaas@gmail.com> wrote:
>> On Sun, Jun 14, 2009 at 1:02 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas <robertmhaas@gmail.com> writes:
>>>> On Sun, Jun 14, 2009 at 11:28 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>>>> However, using BuildTupleFromCStrings is wasteful/stupid for *both*
>>>>> text and xml output, so it seems like getting rid of it is the thing
>>>>> to do here.
>>>
>>>> Makes sense.  However, if we just make that change in do_tup_output(),
>>>> then we'll break the ability to use that function for non-text
>>>> datatypes.
>>>
>>> I'd envision it taking Datums, so it doesn't really matter.  However,
>>> as you say, specializing it to text only wouldn't be much of a loss.
>>
>> I like the Datum option, so I'll work up a patch for that, unless you
>> want to just do it and spare me the trouble.  :-)
>
> Here's an attempt.  Is this anything like what you had in mind?

Hmm... on further review, I'm thinking this is still a bit wastful,
because we don't really need (I think) to call
TupleDescGetAttInMetadata from begin_tup_output_tupdesc.  But I'm not
sure what the best way is to avoid that.  Any thoughts?

...Robert


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

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Should mdxxx functions(e.g. mdread, mdwrite, mdsync etc) PANIC instead of ERROR when I/O failed?
Следующее
От: Gurjeet Singh
Дата:
Сообщение: Re: char() overhead on read-only workloads not so insignifcant as the docs claim it is...