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: | Raw Message | Whole Thread | 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 |