From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Keith Gray <keith(at)heart(dot)com(dot)au> |
Cc: | PostgreSQL Mailing List <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Slow performance on MAX(primary_key) |
Date: | 2002-10-15 08:23:15 |
Message-ID: | 200210150923.15822.dev@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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 simple
cases, and for certain aggregate functions (e.g. not sum()). This means that
the parser would need special-case code to spot these cases, along with tags
for those functions that can be optimised. Thinking further, it might also
vary from type to type. Given that there is a simple workaround and the need
for the optimisation to be added cleanly to the code I believe this has a
fairly low priority.
There is a todo list on the developers' side of the website which has a list
of changes in upcoming releases, you could check there for details.
--
Richard Huxton
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Galbavy | 2002-10-15 10:01:47 | how do i insert an empty string ? |
Previous Message | Richard Huxton | 2002-10-15 08:17:26 | Re: Stored procedure returning row or resultset |