Re: Why we don't want hints

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Why we don't want hints
Date: 2011-02-13 22:52:22
Message-ID: AANLkTi=_+snMF0MxUnYquTh6TB-nKtOAUfVK5VwM15D6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

On Sun, Feb 13, 2011 at 3:29 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> 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)

I fail to see how 1 through 3 can tell the planner the correlation
between two fields in two separate tables.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-02-14 00:06:27 Re: [Mingw-users] mingw64
Previous Message Josh Berkus 2011-02-13 22:29:32 Re: Why we don't want hints

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2011-02-13 22:54:28 Re: choosing the right RAID level for PostgresQL database
Previous Message Josh Berkus 2011-02-13 22:29:32 Re: Why we don't want hints