On 10/17/14, 10:16 PM, Tom Lane wrote:
I wrote:
Because it needs up-to-date min/max values in order to avoid being
seriously misled about selectivities of values near the endpoints.
See commit 40608e7f949fb7e4025c0ddd5be01939adc79eec.
BTW, on re-reading that code I notice that it will happily seize upon
the first suitable index ("first" in OID order), regardless of how many
lower-order columns that index has got. This doesn't make any difference
I think for get_actual_variable_range's own purposes, because it's only
expecting to touch the endmost index page regardless. However, in light
of Marko's complaint maybe we should teach it to check all the indexes
and prefer the matching one with fewest columns? It would only take a
couple extra lines of code, and probably not that many added cycles
considering we're going to do an index access of some sort. But I'm
not sure if it's worth any extra effort --- I think in his example
case, there wasn't any narrower index anyway.
The real cost here isn't the number of columns, it's the size of the index, no?
So shouldn't we look at relpages instead? For example, you'd certainly want to
use an index on (field_we_care_about, smallint_field) over an index on
(field_we_care_about, big_honking_text_field).
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
