Re: Index not being used in MAX function (7.2.3)
От | Chris Gamache |
---|---|
Тема | Re: Index not being used in MAX function (7.2.3) |
Дата | |
Msg-id | 20030611154421.71682.qmail@web13808.mail.yahoo.com обсуждение исходный текст |
Ответ на | Re: Index not being used in MAX function (7.2.3) (Paulo Jan <admin@digital.ddnet.es>) |
Ответы |
Re: Index not being used in MAX function (7.2.3)
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: