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 choice of
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
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 the
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
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.
--
Bruce
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
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.
