From: | "Dann Corbit" <DCorbit(at)connx(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <jim(at)nasby(dot)net> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Index not being used in MAX function (7.2.3) |
Date: | 2003-06-11 17:11:33 |
Message-ID: | D90A5A6C612A39408103E6ECDD77B829408B16@voyager.corporate.connx.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Wednesday, June 11, 2003 10:03 AM
> To: jim(at)nasby(dot)net
> Cc: pgsql-general(at)postgresql(dot)org
> Subject: Re: [GENERAL] Index not being used in MAX function (7.2.3)
>
>
> "Jim C. Nasby" <jim(at)nasby(dot)net> writes:
> > Not to drag this out further, but you might want to hold
> off on that
> > patch. 7.4 is supposed to use indexes for max/min.
>
> Where did you get that idea?
>
> There's been no change in the basic problem, which is that no
> one has proposed a reasonably general method of translating
> aggregates into index manipulations. Postgres has an
> extremely general, extensible concept of aggregates, and
> we're not going to mess it up with some poorly-designed hack.
> But show me a clean design and implementation, and it'll go in.
Is this a poorly designed hack:
Select max(expression) from <join> where <filter>
Becomes:
If (non_hashed_index_exists_on_expression) then
/* Transform expression to: */
select (expression) from <join> where <filter> order by
<expression> limit to 1 rows
else
do_what_you_are_doing_right_now
endif
?
From | Date | Subject | |
---|---|---|---|
Next Message | Dann Corbit | 2003-06-11 17:15:07 | Re: Index not being used in MAX function (7.2.3) |
Previous Message | Tom Lane | 2003-06-11 17:02:57 | Re: Index not being used in MAX function (7.2.3) |