Wouldn't it make sense to optimize max() and min() for indexed columns? I don't
know if I'm barking up the wrong tree, but would it be possible to create an
aggregate (o_max, o_min) to make the query planner treat it differently from
other aggregates? IMO, (if possible...) this would be a more elegant solution
than SQL'ing around the "feature". If it is possible, it might be a nifty
contrib module, poised for inclusion in the production code. Any
takers/thoughts? :)
CG
--- Paulo Jan <admin@digital.ddnet.es> wrote:
> Jonathan Bartlett wrote:
> > Is your index a hash or btree?
> >
> > Jon
> >
>
>
> It's a btree, but anyway, I see that others have already answered my
> question. So it's a "feature" and not a bug? Hrmpf.
> (BTW, the code I was running wasn't written by me; it was part of
> Phorum, a PHP web posting board application. I'll try to patch it to
> make it use "SELECT id... ORDER BY id DESC LIMIT 1" and see how it goes).
>
>
>
> Paulo Jan.
> DDnet.
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com