#re-sequencing

official pg 9.4 doc

http://www.postgresql.org/docs/9.4/static/sql-createindex.html

http://michael.otacoo.com/postgresql-2/postgres-9-4-feature-highlight-refresh-concurrently-a-materialized-view/

oracle

http://www.dba-oracle.com/t_materialized_view_refresh_method_benchmark.htm

http://www.postgresonline.com/journal/archives/313-Caching-data-with-materialized-views-and-statement-level-triggers.html

also resequence your rows based on your matview_index for increased performance.  to the contrary, another post says:

It would only make sense to want the data in a heap table to be physically ordered with the primary key index if you are doing a range scan of the primary key index and then doing a single row lookup in the table. That tends to be relatively uncommon-- you don't commonly want to fetch all the data for ORDER_ID 1-100 from the ORDER table, for example.

which actually sounds like a common scenario contrary to author’s opinion--after all, isn’t this what a activerecord `where` lo-oks like?

based on the discussion above, seems indexing the matview is sufficient, and re sequencing it doing too much.

The two most common operations on a materialized view are query execution and fast refresh, and each operation has different performance requirements. Query execution might need to access any subset of the materialized view key columns, and might need to join and aggregate over a subset of those columns. Consequently, query execution usually performs best if a single-column bitmap index is defined on each materialized view key column.