Re: Spped of max

From: Edmund Dengler <edmundd(at)eSentire(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Spped of max
Date: 2002-05-14 17:35:47
Message-ID: Pine.BSO.4.40.0205141333190.4896-100000@olympus.esentire.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Leland F. Jackson, CPA 2002-05-14 18:14:44 Re: Using COPY
Previous Message Tom Lane 2002-05-14 17:35:45 Re: transitioning postgres oid