Re: BUG #2658: Query not using index
От | Graham Davis |
---|---|
Тема | Re: BUG #2658: Query not using index |
Дата | |
Msg-id | 4522B667.3060002@refractions.net обсуждение исходный текст |
Ответ на | Re: BUG #2658: Query not using index (Chris Browne <cbbrowne@acm.org>) |
Ответы |
Re: BUG #2658: Query not using index
|
Список | pgsql-performance |
Also, the multikey index of (assetid, ts) would already be sorted and that is why using such an index in this case is faster than doing a sequential scan that does the sorting afterwards. Graham. Chris Browne wrote: >gdavis@refractions.net (Graham Davis) writes: > > >>Adding DESC to both columns in the SORT BY did not make the query use >>the multikey index. So both >> >>SELECT DISTINCT ON (assetid) assetid, ts >>FROM asset_positions ORDER BY assetid, ts DESC; >> >>and >> >>SELECT DISTINCT ON (assetid) assetid, ts >>FROM asset_positions ORDER BY assetid DESC, ts DESC; >> >>use the same query plans and both do sequential scans without using >>either the (assetid, ts) or (ts) indexes. Any other ideas on how to >>make this query use an index? Thanks, >> >> > >Why do you want to worsen performance by forcing the use of an index? > >You are reading through the entire table, after all, and doing so via >a sequential scan is normally the fastest way to do that. An index >scan would only be more efficient if you don't have enough space in >memory to store all assetid values. > > -- Graham Davis Refractions Research Inc. gdavis@refractions.net
В списке pgsql-performance по дате отправления: