Message-ID: <3DAE0DB7.70106@clearmetrix.com>
Date: Wed, 16 Oct 2002 21:09:11 -0400
From: "Charles H. Woloszynski" <chw@clearmetrix.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: Keith Gray <keith@heart.com.au>
Cc: Richard Huxton <dev@archonet.com>,
	PostgreSQL Mailing List <pgsql-sql@postgresql.org>
Subject: Re: Slow performance on MAX(primary_key)
References: <20021015071628.57518.qmail@web80304.mail.yahoo.com>
	<3DABC801.8060902@heart.com.au>
	<200210150923.15822.dev@archonet.com>
	<3DAE0883.6090709@heart.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Keith:

I think it would be great to get the optimizer to do something smart on 
such a simple (and common) query.  I am porting an app to Postgresql and 
 I am not looking forward to having to fix all the postgres-ism that 
seem trivial like this.  Postgres gets a bad rap for this kinda simple 
qweak that makes out of the box queries perform slowly and I'd like to 
help improve the image.

Let me know if you need another tester for the fixes.  Currently on 7.2. 
here (7.2.3. I memory serves correct).


Charlie


Keith Gray wrote:

> Richard Huxton wrote:
>
>>>>  As of now, Max() doesn't utilizes the indices hence
>>>> it always do a sequential scan.
>>>
>
>
>>> 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...
>
>
>
> Getting MIN() adn MAX() seems fairly trivial to me.
>
> When is on an index or more importantly Primary
> Key it must be a common SQL.
>
> Would it be possible in the code to look at
> the field in MIN() or MAX() and if it is
> indexed use a similar method to the suggested
> SQL work around?
>
> Can I help this to happen?
>
>
>

-- 


Charles H. Woloszynski

ClearMetrix, Inc.
115 Research Drive
Bethlehem, PA 18015

tel: 610-419-2210 x400
fax: 240-371-3256
web: www.clearmetrix.com