Re: Turning the PLANNER off - Mailing list pgsql-hackers

From David Walker
Subject Re: Turning the PLANNER off
Date
Msg-id 200210290847.19105.pgsql@grax.com
Whole thread Raw
In response to Re: Turning the PLANNER off  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Turning the PLANNER off  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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 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.
>
>
> ---------------------------------------------------------------------------
>
> Ben McMahan wrote:
> > 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 also turn off everything I can except for
> > one type of join (say hash join), and I've turned off geqo.  But I find
> > that the PLANNER still takes an enormous amount of time for some queries.
> >  It doesn't look like the Planner is actually optimizing (changing)
> > anything, but just in case, I was wondering if there was a way to turn
> > off the PLANNER.
> >
> > Note, when I say an enormous amount of time, I mean at least double the
> > time the EXECUTOR takes to actually answer the query.
> >
> > Thanks for your help,
> >
> > Ben McMahan
> >
> > ps. here is a small example of what my queries look like (so you can see
> > if there is something else it might be deciding on):
> >
> > SELECT DISTINCT c0.x1 , c1.x2 , c0.x3 , c0.x4 , c2.x5
> > FROM r1 c4 (x4,x2,x5) JOIN (r0 c3 (x2,x3,x5) JOIN (r2 c2 (x3,x1,x5) JOIN
> > (r1 c1 (x4,x1,x2) JOIN r1 c0 (x1,x3,x4)
> > ON ( c0.x4 = c1.x4  AND  c0.x1 = c1.x1 ))
> > ON ( c0.x3 = c2.x3  AND  c0.x1 = c2.x1 ))
> > ON ( c1.x2 = c3.x2  AND  c0.x3 = c3.x3  AND  c2.x5 = c3.x5 ))
> > ON ( c0.x4 = c4.x4  AND  c1.x2 = c4.x2  AND  c2.x5 = c4.x5 );
> >
> > A quick reminder, FROM r1 c4 (x4,x2,x5) just renames a table r1 into c4
> > where it also renames the columns to x4, x2, and x5 respectively.
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org so that your
> > message can get through to the mailing list cleanly



pgsql-hackers by date:

Previous
From: Jason Tishler
Date:
Subject: Re: Request for supported platforms
Next
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: pg_dump and large files - is this a problem?