Re: Weird performance drop after VACUUM

От: Tom Lane
Тема: Re: Weird performance drop after VACUUM
Дата: ,
Msg-id: 1638.1125157242@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: Weird performance drop after VACUUM  ("Steinar H. Gunderson")
Список: pgsql-performance

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

Weird performance drop after VACUUM  (Ümit Öztosun, )
 Re: Weird performance drop after VACUUM  (asif ali, )
  Re: Weird performance drop after VACUUM  (Philip Hallstrom, )
  Re: Weird performance drop after VACUUM  (Michael Fuhr, )
   Re: Weird performance drop after VACUUM  (asif ali, )
    Re: Weird performance drop after VACUUM  (Michael Fuhr, )
     Re: Weird performance drop after VACUUM  (asif ali, )
      Re: Weird performance drop after VACUUM  (Michael Fuhr, )
       Re: Weird performance drop after VACUUM  (asif ali, )
 Re: Weird performance drop after VACUUM  (Tom Lane, )
  Re: Weird performance drop after VACUUM  (Umit Oztosun, )
  Re: Weird performance drop after VACUUM  ("Steinar H. Gunderson", )
   Re: Weird performance drop after VACUUM  (Tom Lane, )
 Re: Weird performance drop after VACUUM  ("Steinar H. Gunderson", )
  Re: Weird performance drop after VACUUM  (Tom Lane, )

"Steinar H. Gunderson" <> writes:
> On Sat, Aug 27, 2005 at 11:05:01AM -0400, Tom Lane wrote:
>> It could, but it doesn't really have enough information.  We don't
>> currently have any model that some operators are more expensive than
>> others.  IIRC the only sort of reordering the current code will do
>> in a filter condition list is to push clauses involving sub-SELECTs
>> to the end.

> I was more thinking along the lines of reordering "a AND/OR b" to "b AND/OR
> a" if b has lower selectivity than a.

Yeah, but if b is considerably more expensive to evaluate than a, that
could still be a net loss.  To do it correctly you really need to trade
off cost of evaluation against selectivity, and the planner currently
only knows something about the latter (and all too often, not enough :-().

I'd like to do this someday, but until we get some cost info in there
I think it'd be a mistake to do much re-ordering of conditions.
Currently the SQL programmer can determine what happens by writing his
query carefully --- if we reorder based on selectivity only, we could
make things worse, and there'd be no way to override it.

            regards, tom lane


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

От: Tom Lane
Дата:
Сообщение: Re: Weird performance drop after VACUUM
От: Tom Lane
Дата:
Сообщение: Re: Limit + group + join