PostgreSQL Full Text Search

In Short

Professional full text search for folks running Drupal on PostgreSQL 9.0 or higher complete with Views integration, all fully SQL based.

Why

The PostgreSQL RDBMS is capable of doing professional Full Text search, right out of the box. For folks using this database, having to implement Java and Solr on their server in order to be able to perform full text searches within their Drupal installation is rather inefficient.

Not only do people bring extra moving parts on their machines when choosing Solr, which requires extra maintenance, resources and overhead, they also miss out on doing Full Text search without ever needing to leave the SQL language domain.

Solr, and other full text solutions, use their own query language to plow through their index records. In Views, for example, this means you cannot simply mix an existing View (which is based on SQL) with your newly installed Solr, as they are both beasts of a different world. You thus need to resort to all kinds of trickery people had to develop to bring features you are used to in Views, into Views created based on Solr.

With PostgreSQL's full text search capabilities, being pure SQL, you do not have to deliver up on any of such functionalities. Everything Views is capable of, everything any SQL based Views extension is capable of, will still be there, enriched with the power of full text search.

How to use

Please refer to the official documentation for explanations and how-tos regarding the various aspect of this module.

Self-maintaining

The system is self-maintaining. What this means is that this module, in combination with PostgreSQL, will add, update and delete indexed field data when the actual field data is altered. To minimize performance impact, self-maintenance tasks are put on a queue system. The items on these queues are computed on each cron run, so it is vital you have a decently configured Drupal cron setup.

How its done

PostgreSQL Full Text Search takes fields as its base and allows you to index all fields present in your installation. For example: If you have a page node type with a body field attached, you can create an index on this body field, choose which columns of this field you like to index (such as value, summary, format, ...) and choose for which entity/bundles you like this index to be available (whether the entity is a Node, User, Taxonomy, A custom entity, ...).

Fields that do not adhere to Drupal core's own Field API are not available for indexing. A famous example is the node Title field. Please refer to the "How-to: Index title fields" documentation chapter to see how to make such fields available.

PostgreSQL Full Text Views

The submodule PostgreSQL Full Text Search Views, included in this module, brings these indexes right into Views. It does this by providing you with:

1. A exposable filter for each created FTS index
2. A sort mechanism based on FTS ranking
3. A field to highlight found word matches

What it is not

In theory, all fields are indexable. Even non-text fields such as boolean or date fields. However, this project shall never include the ability to provide mechanisms like full text search data range filters and the like.

Why not? First, it makes little sense from a full text search perspective (its all about text after all) and second, there is no need to, everything is *still* SQL. You could use any Views method to search within a date range (such as using the Date modules capabilities). No need to resort to trickery.

All fields indexed with this module will be cast to text before they are indexed.

What is still in the pipeline

I like the principle of releasing early and often - that is why I am throwing this module out in its infancy stage. I consider it to be alpha, which basically means that there are no unit/integration tests operational yet and the module lacks more real world usage.

Also, there are a bunch of features that I would like to develop to make this module even more powerful. A shortlist (points marked with an asterisk are features that I consider a must to implement before pushing a stable release):

• Implement database index management (Gist & Gin) for each created field index with the ability to create multiple database indexes per field index (create database indexes based on query usage) * - done in alpha3
• Implement a Drupal native search page with ranking and spell suggestion
• Implement a Views sort handler based on ranking of lexemes - done in alpha5
• Implement more operators besides the default full text operator *
• Implement full text statistics about the different indexes
• Add the ability to setup different language indexes
• Model an interface to create custom FTS dictionary chains to implement personal stop word lists, synonym lists, ...
• Add the ability to highlight search results * - done in alpha4
• ...

Besides this shortlist, there may be more features or ideas that would fit nicely inside this module which I did not think of yet. I'm open to everyone's input!

Please let me know all your ideas / features / worries via the issue queue.

This module is developed and maintained by Shisaa.jp.