From: | Sam Barnett-Cormack <s(dot)barnett-cormack(at)lancaster(dot)ac(dot)uk> |
---|---|
To: | Hemapriya <priyam_1121(at)yahoo(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Query with Max, Order by is very slow....... |
Date: | 2004-04-07 22:23:17 |
Message-ID: | Pine.LNX.4.58.0404072321340.3239@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-07 22:24:30 | Re: Out of space |
Previous Message | kaolin fire | 2004-04-07 21:59:46 | Re: binary fields |