Re: 7.3.1 New install, large queries are slow

Is this a TODO item?

---------------------------------------------------------------------------

Charles H. Woloszynski wrote:
> I was surprised to hear that JOIN syntax constrained the planner. We
> have a policy of using JOIN syntax to describe the table relationships
> and where clauses to describe the selection process for our queries. It
> was our understanding that the JOIN syntax was introduced to support
> this approach, but not to contrain the planner.
>
> Is there any way to sell the planner to consider JOIN syntax as
> equivalent to WHERE clauses and to not use them to force the planner
> down a specific path? Can we get that added as an option (and then made
> available to use JDBC folks as a URL parameter). It would make my team
> very happy :-).
>
>
> I think that making this an option will help all those migrating to
> Postgres who did not expect that JOINs forced the planner down specific
> plans. Is it possible/reasonable to add?
>
> Charlie
>
>
> Tom Lane wrote:
>
> >"Roman Fail" <rfail(at)posportal(dot)com> writes:
> >
> >
> >>Thanks to everyone for the quick replies! I'm sure that my lack of
> >>skill with SQL queries is the main problem. What's strange to me is
> >>how MSSQL takes my bad queries and makes them look good anyway. It
> >>must have a real smart planner.
> >>
> >>
> >
> >I think more likely the issue is that your use of JOIN syntax is forcing
> >Postgres into a bad plan. MSSQL probably doesn't assign any semantic
> >significance to the use of "a JOIN b" syntax as opposed to "FROM a, b"
> >syntax. Postgres does. Whether this is a bug or a feature depends on
> >your point of view --- but there are folks out there who find it to be
> >a life-saver. You can find some explanations at
> >http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/explicit-joins.html
> >
> >
> >
> >>Is it pretty much universally accepted that I should drop all my
> >>foreign keys?
> >>
> >>
> >
> >No. They don't have any effect on SELECT performance in Postgres.
> >They will impact update speed, but that's not your complaint (at the
> >moment). Don't throw away data integrity protection until you know
> >you need to.
> >
> > regards, tom lane
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 4: Don't 'kill -9' the postmaster
> >
> >
>
> --
>
>
> Charles H. Woloszynski
>
> ClearMetrix, Inc.
> 115 Research Drive
> Bethlehem, PA 18015
>
> tel: 610-419-2210 x400
> fax: 240-371-3256
> web: www.clearmetrix.com
>
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073