"The index is not optimal" GiST warnings

("id" column is a concession to our older generation ORM)

we have a trigger maintained historical archive table documenting the open or closed date ranges documenting when data was visible in the main table:

(essentially the same table but with 'seen' describing the either open-ended (row still visible in housing.unit_funding_source), or closed (row no longer visible) date range. Basic temporal range logging pattern.

My question stems from the building of the GiST constraint to both guard against 'overlapping daterange for same logical row' as well as used for point-in-time queries (i.e. consider only the rows which contain midnight of an arbitrary day, or those which overlap with an entire month). When going by the recipes and we express the constraint with the daterange column and operator && first:

This ends up building a GiST index with 'seen' as the first column:

and provokes the following warning 14 times (on PostgreSQL 9.5):

When rephrasing to have the columns reordered favoring the primary key combination from the original table:

we only get one such warning.

Question: 

It seems that, contrary to expectation / experience with btree indices, that the index backing no_overlapping_rows_two, with 'seen' as the non-leftmost column, still is useable / preferred for daterange-only queries:

# explain analyze select count(*) from  housing.unit_funding_source_snapshot where seen && '[2016-09-01, 2016-10-01)'::daterange;

                                                                                QUERY PLAN                                                                                 

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 Aggregate  (cost=481.83..481.84 rows=1 width=0) (actual time=7.184..7.184 rows=1 loops=1)

   ->  Index Only Scan using no_overlapping_rows_two on unit_funding_source_snapshot  (cost=0.28..456.59 rows=10098 width=0) (actual time=0.074..6.298 rows=10095 loops=1)

          Index Cond: (seen && '[2016-09-01,2016-10-01)'::daterange)

         Heap Fetches: 10095

 Planning time: 0.153 ms

 Execution time: 7.228 ms

(6 rows)

When that constraint / index is dropped, then will opt to use the original index with 'seen' as the leftmost. Is it less preferred due to being a larger index / disoptimal splits having produced a deeper tree?

Searching the web / mailing list archives finds little to nothing regarding "The index is not optimal. To optimize it, contact a developer, or try to use the column as the second one in the CREATE INDEX command."

Should we make the effort to track down these indices / constraints and reorder the columns to put the original table's primary key fields first, then the range column last?

------
James Robinson
Socialserve.com by Emphasys Software