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
Re: slow plan for min/max Re: slow plan for min/max |
Список | 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 по дате отправления: