On Wed, Oct 30, 2002 at 10:59:39PM -0500, Tom Lane wrote:
>
> What's the basis for your assertion that it's "planning things that
> don't need it"? Given a JOIN-constrained query I do not believe the
> planner will look at any cases other than the intended join order.
Well, that was a loose choi
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> So, in the interim, Ben's trying to do it by hand: preorder the joins
> and demonstrate that the 'best' order is in fact the best. Then move on
> to looking into integrating this, if possible: part of the problem is
> recognizing the structure of th
Ah, so Ben finally got around to posting here. Ben's a CS Grad student
here at Rice. His (current) project involves taking some interesting
results from constraint satisfaction and implementing them on a database:
one of the CS faculty has demonstrated that one class of highly joined
DB queries map
David Walker wrote:
> Does PREPARE turn
> select * from mytable
> into
> select mytable.field1,mytable.field2 from mynamespace.mytable
> ?
>
> I was looking for this functionality for one of my projects so I'm curious.
PREPARE turns the query into an internal format used by the executor.
--
Does PREPARE turn
select * from mytable
into
select mytable.field1,mytable.field2 from mynamespace.mytable
?
I was looking for this functionality for one of my projects so I'm curious.
On Monday 28 October 2002 06:55 pm, (Via wrote:
> That is a good question. The planner does more than just a
That is a good question. The planner does more than just analyse the
query. It generates the Plan used by the executor, so that can't be
removed.
It is always a pain when the optimizer/planner takes longer than the
executor. We do have PREPARE/EXECUTE in 7.3beta for you to use.
-
I'm looking at different ways of optimizing queries with a large number of
joins. I write the same query in a number of different ways and compare
the running times. Now the problem is I do not want the optimizer
changing the queries. So I explicit state the order of the joins in the
FROM clause
I'm looking at different ways of optimizing queries with a large number of
joins. I write the same query in a number of different ways and compare
the running times. Now the problem is I do not want the optimizer
changing the queries. So I explicit state the order of the joins in the
FROM clause
