Greg Stark <stark@enterprisedb.com> writes:
> On Sat, Apr 18, 2009 at 1:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm inclined to think that some sort of fuzzy examination of EXPLAIN
>> output (in this example, "are there constant-comparison conditions in
>> the relation scans?") might do the job, but I'm not sure how we'd
>> go about that.
> If we just removed all the costs and other metrics from the explain
> plan and verified that the plan structure was the same would you be
> happy with that? It would still be work to maintain every time the
> planner changed.
> I suppose if we had explain-to-a-table then we could run explain and
> then run an sql query to verify the specific properties we were
> looking for.
> A similar thing could be done with xml if we had powerful enough xml
> predicates but we have a lot more sql skills in-house than xml.
Yeah, I suspect the only really good answers involve the ability to
apply programmable checks to the EXPLAIN output. A SQL-based solution
shouldn't need any external moving parts, whereas analyzing XML output
presumably would.
I guess then one criterion for whether you've built a good output
definition for explain-to-table is whether it's feasible to check this
type of question using SQL predicates.
regards, tom lane
