Re: Query with Max, Order by is very slow.......

Sam Barnett-Cormack <s(dot)barnett-cormack(at)lancaster(dot)ac(dot)uk> writes:
> On Wed, 7 Apr 2004, Hemapriya wrote:
>> Column | Type | Modifiers
>> -----------+-----------------------------+-----------
>> origindb | character(1) | not null
>> uid | integer | not null
>> ...
>> Indexes:
>> "request_pkey" primary key, btree (origindb, uid)
>>
>> select max(uid) from request where originDB=1;

> You really want an index on origindb and uid -

He's got one ;-).

The real problem with this is the datatype mismatch is preventing use of
the index. The query should be

select max(uid) from request where originDB='1';

or else change the datatype of origindb to be integer.

This query will still want to access all the rows with originDB='1',
however. If there are a lot of those then you'll want to use the
order by/limit hack. Correct application of the hack to this case
goes like

regression=# explain select uid from request where originDB='1' order by originDB desc, uid desc limit 1;
QUERY PLAN
--------------------------------------------------------------------------------------------
Limit (cost=0.00..3.41 rows=1 width=9)
-> Index Scan Backward using request_pkey on request (cost=0.00..17.07 rows=5 width=9)
Index Cond: (origindb = '1'::bpchar)
(3 rows)

If EXPLAIN doesn't show you a sort-free plan then you haven't gotten it
right.

regards, tom lane