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

From Jim C. Nasby
Subject Re: Simple join optimized badly?
Date
Msg-id 20061009223030.GW72517@nasby.net
Whole thread Raw
In response to Re: Simple join optimized badly?  (Tobias Brox <tobias@nordicbet.com>)
Responses Re: Simple join optimized badly?  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Simple join optimized badly?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Mon, Oct 09, 2006 at 11:33:03PM +0200, Tobias Brox wrote:
> [Jim C. Nasby - Mon at 04:18:27PM -0500]
> > I can agree to that, but we'll never get any progress so long as every
> > time hints are brought up the response is that they're evil and should
> > never be in the database. I'll also say that a very simple hinting
> > language (ie: allowing you to specify access method for a table, and
> > join methods) would go a huge way towards enabling app developers to get
> > stuff done now while waiting for all these magical optimizer
> > improvements that have been talked about for years.
>
> Just a comment from the side line; can't the rough "set
> enable_seqscan=off" be considered as sort of a hint anyway?  There have
> been situations where we've actually had to resort to such crud.
>
> Beeing able to i.e. force a particular index is something I really
> wouldn't put into the application except for as a very last resort,
> _but_ beeing able to force i.e. the use of a particular index in an
> interactive 'explain analyze'-query would often be ... if not outright
> useful, then at least very interessting.

One of the big problems with doing set enable_...=off is that there's no
way to embed that into something like a view, so you're almost forced
into putting into the application code itself, which makes matters even
worse. If you could hint this within a query (maybe even on a per-table
level), you could at least encapsulate that into a view.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

pgsql-performance by date:

Previous
From: Tobias Brox
Date:
Subject: Re: Simple join optimized badly?
Next
From: Tom Lane
Date:
Subject: Re: Simple join optimized badly?