Re: Hints WAS: Index Tuning Features

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

In response to

Browse pgsql-hackers by date

  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