Re: Seqscan in MAX(index_column) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Seqscan in MAX(index_column)
Date
Msg-id 87vfs78bk6.fsf@stark.dyndns.tv
Whole thread Raw
In response to Re: Seqscan in MAX(index_column)  ("scott.marlowe" <scott.marlowe@ihs.com>)
Responses Re: Seqscan in MAX(index_column)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"scott.marlowe" <scott.marlowe@ihs.com> writes:

> Would it be possible to catch an unconstrained max(id)/min(id) and rewrite 
> it as "select id from table order by id [desc] limit1" on the fly in the 
> parser somewhere?
> 
> That would require fairly little code, and be transparent to the user.  
> I.e. low hanging fruit.

What if there's no index on id? Then it would actually be slower than the
straightforward approach. You would have to check both versions and take the
one with the lowest cost, or check before rewriting for possible paths on that
column.

The problem with low hanging fruit is sometimes it makes people stop looking
for real solutions. And I think the real solution is worthwhile here.

-- 
greg



pgsql-hackers by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: Seqscan in MAX(index_column)
Next
From: Jeroen Ruigrok/asmodai
Date:
Subject: Re: 64-bit pgsql