From: | Shaun Thomas <sthomas(at)peak6(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Why we don't want hints Was: Slow count(*) again... |
Date: | 2011-02-10 17:06:42 |
Message-ID: | 4D541B22.9080000@peak6.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On 02/10/2011 10:45 AM, Kevin Grittner wrote:
> Even there I would tend to think that the sort of "do it this way"
> hints that people seem to initially want wouldn't be good; it should
> be a way to override the costing factor which the optimizer gets
> wrong, so it can do its usual excellent job of evaluating plans with
> accurate costs.
You know... that's an interesting approach. We already do that with
functions by allowing users to specify the estimated cost, rows
returned, and even override config settings. It's an inexact science at
best, but it might help the optimizer out.
Really... how difficult would it be to add that syntax to the JOIN
statement, for example?
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas(at)peak6(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Thomas | 2011-02-10 17:09:18 | Re: Why we don't want hints Was: Slow count(*) again... |
Previous Message | Tom Lane | 2011-02-10 17:04:19 | Re: Range Types (catversion.h) |
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Thomas | 2011-02-10 17:09:18 | Re: Why we don't want hints Was: Slow count(*) again... |
Previous Message | Robert Haas | 2011-02-10 17:02:58 | Re: Why we don't want hints Was: Slow count(*) again... |