Re: Simple join optimized badly? - Mailing list pgsql-performance

From Jim C. Nasby
Subject Re: Simple join optimized badly?
Date
Msg-id 20061010142101.GD72517@nasby.net
Whole thread Raw
In response to Re: Simple join optimized badly?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Simple join optimized badly?
List pgsql-performance
On Tue, Oct 10, 2006 at 10:14:48AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jim@nasby.net> writes:
> > I'd rather have the ugly solution sooner rather than the elegant one
> > later (if ever).
>
> The trouble with that is that we couldn't ever get rid of it, and we'd
> be stuck with backward-compatibility concerns with the first (over
> simplified) design.  It's important to get it right the first time,
> at least for stuff that you know perfectly well is going to end up
> embedded in application code.

We've depricated things before, I'm sure we'll do it again. Yes, it's a
pain, but it's better than not having anything release after release.
And having a formal hint language would at least allow us to eventually
clean up some of these oddball cases, like the OFFSET 0 hack.

I'm also not convinced that even supplimental statistics will be enough
to ensure the planner always does the right thing, so query-level hints
may have to stay (though it'd be great if that wasn't the case).
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

pgsql-performance by date:

Previous
From: "Steinar H. Gunderson"
Date:
Subject: Re: Simple join optimized badly?
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Simple join optimized badly?