| From: | Sean Chittenden <sean(at)chittenden(dot)org> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | pgsql-hackers(at)postgreSQL(dot)org, pgsql-performance(at)postgreSQL(dot)org | 
| Subject: | Re: [PERFORM] Proposal: relaxing link between explicit JOINs and execution order | 
| Date: | 2003-01-22 23:59:31 | 
| Message-ID: | 20030122235931.GE12075@perrin.int.nxad.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance | 
> There's been some recent discussion about the fact that Postgres
> treats explicit JOIN syntax as constraining the actual join plan, cf
> http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/explicit-joins.html
> 
> This behavior was originally in there simply because of lack of time
> to consider alternatives.  I now realize that it wouldn't be hard to
> get the planner to do better --- basically, preprocess_jointree just
> has to be willing to fold JoinExpr-under-JoinExpr into a FromExpr
> when the joins are inner joins.
> 
> But in the meantime, some folks have found the present behavior to be
> a feature rather than a bug, since it lets them control planning time
> on many-table queries.  If we are going to change it, I think we need
> some way to accommodate both camps.
[snip]
> Comments?  In particular, can anyone think of pithy names for these
> variables?  The best I'd been able to come up with is
> MAX_JOIN_COLLAPSE and MAX_FROM_COLLAPSE, but neither of these
> exactly sing...
How about something that's runtime tunable via a SET/SHOW config var?
There are some queries that I have that I haven't spent any time
tuning and would love to have the planner spend its CPU thinking about
it instead of mine.  Setting it to 2 by default, then on my tuned
queries, setting to something obscenely high so the planner won't muck
with what I know is fastest (or so I think at least).
I know this is a can of worms, but what about piggy backing on an
Oracle notation and having an inline way of setting this inside of a
comment?
SELECT /* +planner:collapse_tables=12  */ ....  ?
           ^^^^^^^ ^^^^^^^^^^^^^^^ ^^^
	   system  variable        value
::shrug:: In brainstorm mode. Anyway, a few names:
auto_order_join
auto_order_join_max
auto_reorder_table_limit
auto_collapse_join
auto_collapse_num_join
auto_join_threshold
When I'm thinking about what this variable will do for me as a DBA, I
think it will make the plan more intelligent by reordering the joins.
My $0.02.  -sc
-- 
Sean Chittenden
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-01-23 00:04:02 | Re: Terrible performance on wide selects | 
| Previous Message | Dann Corbit | 2003-01-22 23:56:55 | Re: Terrible performance on wide selects | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-01-23 00:04:02 | Re: Terrible performance on wide selects | 
| Previous Message | Dann Corbit | 2003-01-22 23:56:55 | Re: Terrible performance on wide selects |