Re: Query with Max, Order by is very slow.......
От | Sam Barnett-Cormack |
---|---|
Тема | Re: Query with Max, Order by is very slow....... |
Дата | |
Msg-id | Pine.LNX.4.58.0404072321340.3239@localhost.localdomain обсуждение исходный текст |
Ответ на | Query with Max, Order by is very slow....... (Hemapriya <priyam_1121@yahoo.com>) |
Ответы |
Re: Query with Max, Order by is very slow.......
|
Список | 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
В списке pgsql-admin по дате отправления: