Jonah H. Harris said: > Tom Lane wrote: > >>The fundamental problem is that you can't do it without adding at least >>16 bytes, probably 20, to the size of an index tuple header. That >>would double the physical size of an index on a simple column (eg an >>integer or timestamp). The extra I/O costs and extra maintenance costs >>are unattractive to say the least. And it takes away some of the >>justification for the whole thing, which is that reading an index is >>much cheaper than reading the main table. That's only true if the >>index is much smaller than the main table ... >> > I recognize the added cost of implementing index only scans. As > storage is relatively cheap these days, everyone I know is more > concerned about faster access to data. Similarly, it would still be > faster to scan the indexes than to perform a sequential scan over the > entire relation for this case. I also acknowledge that it would be a > negative impact to indexes where this type of acces isn't required, as > you suggested and which is more than likely not the case. I just > wonder what more people would be happier with and whether the added > 16-20 bytes would be > extremely noticable considering most 1-3 year old hardware. > >
Monetary cost is not the issue - cost in time is the issue. cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
