Content-Type: text/plain;
  charset="iso-8859-1"
From: Richard Huxton <dev@archonet.com>
Organization: Archonet Ltd
To: Keith Gray <keith@heart.com.au>
Subject: Re: Slow performance on MAX(primary_key)
Date: Tue, 15 Oct 2002 09:23:15 +0100
User-Agent: KMail/1.4.3
Cc: PostgreSQL Mailing List <pgsql-sql@postgresql.org>
References: <20021015071628.57518.qmail@web80304.mail.yahoo.com>
	<3DABC801.8060902@heart.com.au>
In-Reply-To: <3DABC801.8060902@heart.com.au>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200210150923.15822.dev@archonet.com>

On Tuesday 15 Oct 2002 8:47 am, Keith Gray wrote:
> Ludwig Lim wrote:
> >   As of now, Max() doesn't utilizes the indices hence
> > it always do a sequential scan.
>
> Thanks Ludwig,
>
> That does help performance, but I was using a "standard"
> SQL command wrapped in a VB6 ADO ODBC program.
>
> Is this likely to be sorted in 7.2 ?
> Is anyone looking at this?

As I understand, the problem is that the optimisation only applies for simp=
le=20
cases, and for certain aggregate functions (e.g. not sum()). This means tha=
t=20
the parser would need special-case code to spot these cases, along with tag=
s=20
for those functions that can be optimised. Thinking further, it might also=
=20
vary from type to type. Given that there is a simple workaround and the nee=
d=20
for the optimisation to be added cleanly to the code I believe this has a=
=20
fairly low priority.

There is a todo list on the developers' side of the website which has a lis=
t=20
of changes in upcoming releases, you could check there for details.

--=20
  Richard Huxton