From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | Pailloncy Jean-Gérard <pailloncy(at)ifrance(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: slow plan for min/max |
Date: | 2003-09-08 20:37:10 |
Message-ID: | Pine.LNX.4.33.0309081434150.11709-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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?
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-09-08 21:26:16 | Re: slow plan for min/max |
Previous Message | Christopher Browne | 2003-09-08 19:32:16 | Re: slow plan for min/max |