Re: Why we don't want hints Was: Slow count(*) again...

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

In response to

Responses

Browse pgsql-hackers by date

  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)

Browse pgsql-performance by date

  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...