Re: slow plan for min/max

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: slow plan for min/max
Дата
Msg-id Pine.LNX.4.33.0309081434150.11709-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: slow plan for min/max  (Neil Conway <neilc@samurai.com>)
Ответы Re: slow plan for min/max  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: slow plan for min/max  (Josh Berkus <josh@agliodbs.com>)
Re: slow plan for min/max  (Greg Stark <gsstark@mit.edu>)
Список pgsql-performance
On Mon, 8 Sep 2003, Neil Conway wrote:

> On Mon, 2003-09-08 at 11:56, scott.marlowe wrote:
> > Basically, Postgresql uses an MVCC locking system that makes massively
> > parallel operation possible, but costs in certain areas, and one of those
> > areas is aggregate performance over large sets.  MVCC makes it very hard
> > to optimize all but the simplest of aggregates, and even those
> > optimzations which are possible would wind up being quite ugly at the
> > parser level.
>
> 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?



В списке pgsql-performance по дате отправления:

Предыдущее
От: Christopher Browne
Дата:
Сообщение: Re: slow plan for min/max
Следующее
От: Tom Lane
Дата:
Сообщение: Re: slow plan for min/max