Re: slow plan for min/max

От: Tom Lane
Тема: Re: slow plan for min/max
Дата: ,
Msg-id: 3303.1063056376@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: slow plan for min/max  ("scott.marlowe")
Ответы: Re: slow plan for min/max  (Thomas Swan)
Список: pgsql-performance

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

slow plan for min/max  (Pailloncy Jean-Gérard, )
 Re: slow plan for min/max  ("scott.marlowe", )
  Re: slow plan for min/max  (Neil Conway, )
   Re: slow plan for min/max  ("scott.marlowe", )
    Re: slow plan for min/max  (Tom Lane, )
     Re: slow plan for min/max  (Thomas Swan, )
      Re: slow plan for min/max  (Bruno Wolff III, )
    Re: slow plan for min/max  (Josh Berkus, )
    Re: slow plan for min/max  (Greg Stark, )
     Re: slow plan for min/max  (Josh Berkus, )
     Re: slow plan for min/max  (Bruno Wolff III, )
   Re: slow plan for min/max  (Christopher Browne, )
  Re: slow plan for min/max  (Greg Stark, )
  Re: slow plan for min/max  ("Matt Clark", )
   Re: slow plan for min/max  ("Matt Clark", )
   Re: slow plan for min/max  (Tom Lane, )
    Re: slow plan for min/max  ("Matt Clark", )
     Re: slow plan for min/max  (Tom Lane, )
      Re: slow plan for min/max  ("Matt Clark", )
 Re: slow plan for min/max  (Christopher Browne, )
 Re: slow plan for min/max  (Pailloncy Jean-Gérard, )

"scott.marlowe" <> writes:
> On Mon, 8 Sep 2003, Neil Conway wrote:
>> As was pointed out in a thread a couple days ago, MIN/MAX() optimization
>> has absolutely nothing to do with MVCC. It does, however, make
>> optimizing COUNT() more difficult.

> Not exactly.  While max(id) is easily optimized by query replacement,
> more complex aggregates will still have perfomance issues that would not
> be present in a row locking database.  i.e. max((field1/field2)*field3) is
> still going to cost more to process, isn't it?

Er, what makes you think that would be cheap in any database?

Postgres would actually have an advantage given its support for
expressional indexes (nee functional indexes).  If we had an optimizer
transform to convert MAX() into an index scan, I would expect it to be
able to match up max((field1/field2)*field3) with an index on
((field1/field2)*field3).

            regards, tom lane


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

От: Tom Lane
Дата:
Сообщение: Re: Quick question
От: "Waruna Geekiyanage"
Дата:
Сообщение: Slow query?