Обсуждение: Query with Max, Order by is very slow.......

Hi,

we have table having 23 million rows.
This is the table structure.
Table Request:

  Column   |            Type             | Modifiers
-----------+-----------------------------+-----------
 origindb  | character(1)                | not null
 uid       | integer                     | not null
 rtype     | integer                     |
 senderid  | integer                     |
 destaddr  | character varying(15)       |
 opid      | integer                     |
 devmodel  | integer                     |
 ikind     | integer                     |
 itemid    | character varying(10)       |
 tranfk    | integer                     |
 enteredon | timestamp without time zone |
 status    | integer                     |
 accountid | integer                     |
Indexes:
    "request_pkey" primary key, btree (origindb, uid)

I do max Query like this

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

it took around 20 min to return the result..  Since
max, count functions do the full table scan, i tried
the workaround given..

select uid from request where originDB=1 order by uid
desc limit 1;

this query runs forever.. i tried even without where
condition..no result..

I'm not able to figure out what could be the reason..
can anybody help?

Thanks in Advance

Regards
Priya


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/

On Wed, 7 Apr 2004, Hemapriya wrote:

> Hi,
>
> we have table having 23 million rows.
> This is the table structure.
> Table Request:
>
>   Column   |            Type             | Modifiers
> -----------+-----------------------------+-----------
>  origindb  | character(1)                | not null
>  uid       | integer                     | not null
>  rtype     | integer                     |
>  senderid  | integer                     |
>  destaddr  | character varying(15)       |
>  opid      | integer                     |
>  devmodel  | integer                     |
>  ikind     | integer                     |
>  itemid    | character varying(10)       |
>  tranfk    | integer                     |
>  enteredon | timestamp without time zone |
>  status    | integer                     |
>  accountid | integer                     |
> Indexes:
>     "request_pkey" primary key, btree (origindb, uid)
>
> I do max Query like this
>
> select max(uid) from request where originDB=1;
>
> it took around 20 min to return the result..  Since
> max, count functions do the full table scan, i tried
> the workaround given..
>
> select uid from request where originDB=1 order by uid
> desc limit 1;
>
> this query runs forever.. i tried even without where
> condition..no result..

You really want an index on origindb and uid - the order by ... desc
limit 1 workaround is only quick if there's an index on the order by
field, and and where clause is faster if it can use an index to speed up
the query. I would say you might want an index on both of them together,
a joint index.

--

Sam Barnett-Cormack
Software Developer                           |  Student of Physics & Maths
UK Mirror Service (http://www.mirror.ac.uk)  |  Lancaster University

On Wed, Apr 07, 2004 at 14:03:54 -0700,
  Hemapriya <priyam_1121@yahoo.com> wrote:
> Indexes:
>     "request_pkey" primary key, btree (origindb, uid)
>
> I do max Query like this
>
> select max(uid) from request where originDB=1;
>
> it took around 20 min to return the result..  Since
> max, count functions do the full table scan, i tried
> the workaround given..
>
> select uid from request where originDB=1 order by uid
> desc limit 1;
>
> this query runs forever.. i tried even without where
> condition..no result..

Because the index is on both origindb and uid and the planner doesn't
know that it can use this index when origindb is fixed but you are
ordering on uid, you need to rewrite the query slightly.
Try using:
select uid from request where originDB=1
  order by origindb desc, uid desc limit 1;

Sam Barnett-Cormack <s.barnett-cormack@lancaster.ac.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