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