From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Why we don't want hints |
Date: | 2011-02-13 22:29:32 |
Message-ID: | 4D585B4C.5020602@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
I've wordsmithed Chris's changes some, and then spun off a completely
separate page for Hints discussion, since the NotToDo item was becoming
too long.
> Something like this syntax?:
>
> JOIN WITH (correlation_factor=0.3)
Please, NO!
This is exactly the kind of hint that I regard as a last resort if we
run out of implementation alternatives. Any hint which gets coded into
the actual queries becomes a *massive* maintenance and upgrade headache
thereafter. If we're implementing a hint alternative, we should look at
stuff in this priority order:
1. Useful tuning of additional cost parameters by GUC (i.e.
cursor_tuple_fraction)
2. Modifying cost parameters on database *objects* (i.e. "ndistinct=500")
3. Adding new parameters to modify on database objects (i.e.
"distribution=normal(1.5,17)","new_rows=0.1")
4. Query hints (if all of the above fails to give fixes for some tested
problem)
> Where exactly are the problems with other systems noted? Most other
> systems have this option so saying "They have problems" is a giant cop
> out.
I've put my list down:
http://wiki.postgresql.org/wiki/OptimizerHintsDiscussion#Problems_with_existing_Hint_stystems
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2011-02-13 22:52:22 | Re: Why we don't want hints |
Previous Message | Dimitri Fontaine | 2011-02-13 21:06:32 | Re: Extensions vs PGXS' MODULE_PATHNAME handling |
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2011-02-13 22:52:22 | Re: Why we don't want hints |
Previous Message | Rob Wultsch | 2011-02-13 20:40:09 | Re: Why we don't want hints |