Skip site navigation (1) Skip section navigation (2)

Re: generic explain options v3

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-07-22 02:29:45
Subject: Re: generic explain options v3
Previous:From: Tom LaneDate: 2009-07-22 01:32:09
Subject: Re: Higher TOAST compression.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group