Sam Barnett-Cormack <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
