Yet another btree gotcha

I am wondering whether it's normal to see dropping a btree improve the
query which could never complete enough that it completes in a blink?

I realize the data I have here represent the worst possible input to
btree, and I'm probably better off without any index at all, but I
guess it is something that the optimizer or the access method itself
should be able to decide.

I am joining two tables, "km" and "su" on an int2 attribute, "item".
Just take a look at the value histograms for item:

emp=> SELECT item, count (*) AS count FROM km GROUP BY item;
item|count
----+-----
   1|31262
   2|  110
   3|    3
   4|    1
(4 rows)

emp=> SELECT item, count (*) AS count FROM su GROUP BY item;
item|count
----+-----
   1|94108
   2| 1697
   3|  773
   4|  482
   5|  237
   6|  146
   7|  105
   8|   68
   9|   41
  10|   29
  11|   22
  12|   15
  13|   13
  14|    8
  15|    7
  16|    6
  17|    5
  18|    4
  19|    4
  20|    4
  21|    4
  22|    3
  23|    3
  24|    3
  25|    1
  26|    1
  27|    1
  28|    1
  29|    1
  30|    1
  31|    1

As a default rule, I used to create the btree indices for all integer
types, regardless of their values. Not anymore. It took me quite a
while to figure that the following query did not work because of the
faulty btree index on "item" (other joined attributes are char()):

SELECT km.km, su.su
  FROM km, su
  WHERE km.id = su.id
    AND km.rel = su.rel
    AND km.item = su.item
    AND su ~ '^ethanol';

Can the btree or any other AM be smart enough and bail out from CREATE
INDEX saying, "your data isn't worth indexing"?

--Gene