Index usage for sorted query
От | Markus Schaber |
---|---|
Тема | Index usage for sorted query |
Дата | |
Msg-id | 20041120151710.695f4de5@kingfisher.intern.logi-track.com обсуждение исходный текст |
Ответы |
Re: Index usage for sorted query
Re: Index usage for sorted query |
Список | pgsql-performance |
Hello, I have the following query plan: logigis=# explain SELECT geom, ref_in_id as ref, nref_in_id as nref, st_name as name, substr(l_postcode,1,2) as postfirst, func_class as level FROM schabi.streets WHERE cd='ca' ORDER BY l_postcode; QUERY PLAN --------------------------------------------------------------------------------------------------- Sort (cost=2950123.42..2952466.07 rows=937059 width=290) Sort Key: l_postcode -> Index Scan using streets_name_idx on streets (cost=0.00..2857177.57 rows=937059 width=290) Index Cond: ((cd)::text = 'ca'::text) And I have, beside others, the following index: »streets_name_idx« btree (cd, l_postcode) As the query plan shows, my postgresql 7.4 does fine on using the index for the WHERE clause. But as it fetches all the rows through the index, why doesn't it recognize that, fetching this way, the rows are already sorted by l_postcode? As I have a larger set of data, it nearly breaks down our developer machine every time we do this, as it always creates a temporary copy of the large amount of data to sort it (setting sort_mem higher makes it swap, setting it lower makes it thrashing disk directly). Is Postgresql 8 more intelligend in this case? Thanks for your hints, Markus -- markus schaber | dipl. informatiker logi-track ag | rennweg 14-16 | ch 8001 zürich phone +41-43-888 62 52 | fax +41-43-888 62 53 mailto:schabios@logi-track.com | www.logi-track.com
В списке pgsql-performance по дате отправления: