Re: Spped of max
От | Edmund Dengler |
---|---|
Тема | Re: Spped of max |
Дата | |
Msg-id | Pine.BSO.4.40.0205141333190.4896-100000@olympus.esentire.com обсуждение исходный текст |
Ответ на | Spped of max (Edmund Dengler <edmundd@eSentire.com>) |
Ответы |
Re: Spped of max
|
Список | pgsql-general |
Whoops, a litle fast on the keyboard. This bit about: >I mean, isn't this really equivalent to: > >explain select max(event_id) from (select event_id from syslog_event order >by event_id desc limit 1) as syslog_event; >NOTICE: QUERY PLAN: > >Aggregate (cost=0.70..0.70 rows=1 width=8) > -> Subquery Scan syslog_event (cost=0.00..0.70 rows=1 width=8) > -> Limit (cost=0.00..0.70 rows=1 width=8) > -> Index Scan Backward using syslog_event_pkey on syslog_event (cost=0.00..2435803.36 rows=3490163 width=8) > can obviously be shortened to: explain select event_id from syslog_event order by event_id desc limit 1; NOTICE: QUERY PLAN: Limit (cost=0.00..0.70 rows=1 width=8) -> Index Scan Backward using syslog_event_pkey on syslog_event (cost=0.00..2435803.36 rows=3490163 width=8) Ed which flies as expected? Now, this type of thing gets me real worried about how good the optimizer really is. I have a number of fairly complicated queries that are created via criteria from the web, and it would be a pain to get them all "hand-optimized" if I cannot rely on the optimizer at least picking reasonable methods. Miscellaneous: Using 7.2.1 under OpenBSD 3.0 Ed
В списке pgsql-general по дате отправления: