From: | "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Josh Berkus" <josh(at)agliodbs(dot)com>, "Mark Woodward" <pgsql(at)mohawksoft(dot)com> |
Cc: | "Christopher Browne" <cbbrowne(at)acm(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hints WAS: Index Tuning Features |
Date: | 2006-10-13 09:44:20 |
Message-ID: | E1539E0ED7043848906A8FF995BDA579016A09CC@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> And, to give you a starting point: the discussion has morphed into:
> "What manual ways can we come up with for the DBA to
> influence the planner and fix planner "bugs" which won't have
> the fragility of query-based hints ala Oracle?"
I see a few downsides though:
1. it lacks a way to try out different plans in one session
without actually influencing other sessions.
Maybe the way to do this is:
begin work;
add statistics hints
explain analyze your select
rollback work;
this is not enough to try a whole program with a new manual correction
though.
2. To try out sensible plans would only work if there where ways that
allow all
nodetypes (on specific tables/where clauses) to be made more/less
expensive individually.
3. the manual entry may negatively influence other queries that
previously were fast
thus a typical tuning measure for one bad query plan imposes
high risk
4. sometimes I know as a developer that certain queries only run in case
of
abnormal skew in data (e.g. I expect to get a lot of rows even if
usually i would get few)
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Arturo Perez | 2006-10-13 12:01:13 | Re: Hints (Was: Index Tuning Features) |
Previous Message | Zeugswetter Andreas ADI SD | 2006-10-13 09:07:29 | Re: [HACKERS] Hints proposal |