Re: FW: Simple join optimized badly?

От: Jim C. Nasby
Тема: Re: FW: Simple join optimized badly?
Дата: ,
Msg-id: 20061012135248.GS28647@nasby.net
(см: обсуждение, исходный текст)
Ответ на: Re: FW: Simple join optimized badly?  (Mark Kirkwood)
Ответы: Re: FW: Simple join optimized badly?  (Tom Lane)
Список: pgsql-performance

Скрыть дерево обсуждения

FW: Simple join optimized badly?  ("H.J. Sanders", )
 Re: FW: Simple join optimized badly?  (Mark Kirkwood, )
  Re: FW: Simple join optimized badly?  ("Jim C. Nasby", )
   Re: FW: Simple join optimized badly?  (Tom Lane, )
    Re: FW: Simple join optimized badly?  ("Jim C. Nasby", )
     Re: FW: Simple join optimized badly?  (Mark Kirkwood, )
    Re: FW: Simple join optimized badly?  (Scott Marlowe, )
    Re: FW: Simple join optimized badly?  (Mark Kirkwood, )

On Thu, Oct 12, 2006 at 10:59:23PM +1300, Mark Kirkwood wrote:
> H.J. Sanders wrote:
>
> > why not just like in some other (commercial) databases:
> >
> > a statement to say: use index ............
> >
> > I know this is against all though but if even the big ones can not resist
> > the pressure of their users, why not?
> >
>
> Yeah - some could not (e.g. Oracle), but some did (e.g. DB2), and it
> seemed (to me anyway) significant DB2's optimizer worked much better
> than Oracle's last time I used both of them (Oracle 8/9 and DB2 7/8).

If someone's going to commit to putting effort into improving the
planner then that's wonderful. But I can't recall any significant
planner improvements since min/max (which I'd argue was more of a bug
fix than an improvement). In fact, IIRC it took at least 2 major
versions to get min/max fixed, and that was a case where it was very
clear-cut what had to be done.
--
Jim Nasby                                            
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


В списке pgsql-performance по дате сообщения:

От: "Jim C. Nasby"
Дата:
Сообщение: Re: Hints proposal
От: Josh Berkus
Дата:
Сообщение: Re: [HACKERS] Hints proposal