From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: generic explain options v3 |
Date: | 2009-07-22 02:05:30 |
Message-ID: | 8554.1248228330@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jul 21, 2009 at 7:47 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Also, I'd suggest changing the ExplainStmt struct to have a list of
>> DefElem options instead of hard-wiring the option set at that level.
> What is the advantage of that?
Fewer places to change when you add a new option; in particular, not
copyfuncs or equalfuncs. Also, the way you are doing it is gratuitously
unlike every other command that has similar issues to deal with.
Everybody else parses their DefElem list at execution time. I think
you should have the legacy ANALYZE and VERBOSE syntax elements generate
DefElem list members that get examined at execution.
BTW, I see that your "explain refactoring" patch is marked ready
for committer, but is it actually sane to apply it before the other
two?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-07-22 02:29:45 | Re: generic explain options v3 |
Previous Message | Tom Lane | 2009-07-22 01:32:09 | Re: Higher TOAST compression. |