From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
---|---|
To: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
Cc: | Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Simple join optimized badly? |
Date: | 2006-10-11 00:34:53 |
Message-ID: | 452C3C2D.6000008@paradise.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jim C. Nasby wrote:
> (snippage)... 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.
It is possibly because some of us feel they are evil :-) (can't speak
for the *real* Pg developers, just my 2c here)
As for optimizer improvements well, yeah we all want those - but the
basic problem (as I think Tom stated) is the developer resources to do
them. As an aside this applies to hints as well - even if we have a
patch to start off with - look at how much time bitmap indexes have been
worked on to get them ready for release....
Personally I don't agree with the oft stated comment along the lines of
"we will never get the optimizer to the point where it does not need
some form of hinting" as:
1/ we don't know that to be a true statement, and
2/ it is kind of admitting defeat on a very interesting problem, when in
fact a great deal of progress has been made to date, obviously by people
who believe it is possible to build a "start enough" optimizer.
best wishes
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2006-10-11 00:36:39 | Re: Simple join optimized badly? |
Previous Message | Brendan Curran | 2006-10-10 23:46:18 | Re: Scrub one large table against another |