Re: Optimizer : query rewrite and execution plan ?

From: "Roberts, Jon" <Jon(dot)Roberts(at)asurion(dot)com>
To: "Erik Jones" <erik(at)myemma(dot)com>
Cc: <theo(at)flame(dot)co(dot)za>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Optimizer : query rewrite and execution plan ?
Date: 2008-02-06 15:35:47
Message-ID: 1A6E6D554222284AB25ABE3229A92762715551@nrtexcus702.int.asurion.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> >
> >>> Since the SQL is not your fault and difficult to control, it is an
> >>> argument in favour of an optional planner mode that would perform
> >>> additional checks for redundant clauses of various kinds. The
> > default
> >>> for that would be "off" since most people don't suffer from this
> >>> problem. BO isn't the only SQL generating-client out there, so I
> > think
> >>> this is a fairly wide problem.
> >>
> >> I would have to disagree. I spend a lot of time writing code that
> >> generates SQL from a business app and feel strongly that any
> >> optimisation is my responsibility.
> >>
> >
> > The point to a BI tool like BO is to abstract the data collection
> > and do
> > it dynamically. The SQL is built at run time because the tool is
> > designed to give the end user as much flexibility as the data
> > structure
> > allows to query the data however they want.
> >
> > It isn't feasible, possible, or recommended to rewrite all of the
> > possible generated SQL that could be designed at runtime by the
tool.
>
> No, but it is feasible to expect the tool to generate well-formed
> queries without redundant clauses. There are plenty that do.
>

Agreed.

Jon

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2008-02-06 15:40:20 Re: Benchmark Data requested
Previous Message Erik Jones 2008-02-06 15:27:33 Re: Optimizer : query rewrite and execution plan ?