Re: Need more speed from this.
От | Tom Lane |
---|---|
Тема | Re: Need more speed from this. |
Дата | |
Msg-id | 23183.1006210093@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Need more speed from this. (wsheldah@lexmark.com) |
Список | pgsql-general |
wsheldah@lexmark.com writes: > Aggregate (cost=17296.84..17296.84 rows=1 width=8) > -> Index Scan using data_type_id_idx on system_data > (cost=0.00..17296.84 rows=1 width=8) That's an awfully high cost for an indexscan that's only supposed to return one row! I'd guess that in fact the indexscan itself is returning a lot of rows, and that the reduction to a small number of rows comes mostly from applying the restrictions on date and server_id (which actually happens above the index search, though you can't see the difference in EXPLAIN's depiction). How many rows are there with data_type_id = 8? Merely having an index is not much help if the index is unselective, which is to say that there aren't many distinct values in the indexed column. It would seem though that the system thinks the data_type_id index is the best alternative it's got. Would scanning on server_id yield a smaller number of matches in the index? How about date, or a multicolumn index combining some of these fields? regards, tom lane
В списке pgsql-general по дате отправления: