Comment 7 for bug 788379

James, GIN indexes are (probably) fine for Evergreen. They build slower, but run much faster. The primary runtime drawback is that if you feed them a empty (NULL) query (which we're pretty good a guarding against in 2.0+, thanks to QueryParser and some in-SQL sanity checks) the query will explode in an ugly way (but, on the up side, quickly). A secondary consideration is that they become bloated much faster than GiST indexes. But, bibliographic data probably doesn't change fast enough for that to be a problem in practice, and autovac should make that problem mostly transparent anyway.

All in all, I'd support (though can't promise to code for) officially switching to GIN for all FTS indexing in 2.2 by way of looking for all GiST indexes and creating duplicates of those using GIN and then dropping the GiST version. This can be done live using CREATE INDEX CONCURRENTLY. GIN indexes have been WAL'd for a while now, so I'm quite comfortable with them, personally.

Regarding the 'tnf' title sorting, this goes away in 2.1, as SVF supplies a stock 'titlesort' attribute (as well as 'authorsort', both of which are directly indexed by default).