postgres_search.rst 4.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130
  1. .. _postgres_search:
  2. ========================
  3. PostgreSQL search engine
  4. ========================
  5. .. warning::
  6. | This search backend is deprecated, and has been replaced by ``wagtail.search.backends.database``. See :ref:`wagtailsearch_backends`.
  7. This contrib module provides a search engine backend using
  8. `PostgreSQL full-text search capabilities <https://www.postgresql.org/docs/current/static/textsearch.html>`_.
  9. .. warning::
  10. | You can only use this module to index data from a PostgreSQL database.
  11. **Features**:
  12. - It supports all the search features available in Wagtail.
  13. - Easy to install and adds no external dependency or service.
  14. - Excellent performance for sites with up to 200 000 pages and stays decent for sites up to a million pages.
  15. - Faster to reindex than Elasticsearch, if you use PostgreSQL 9.5 or higher.
  16. **Drawbacks**:
  17. - Partial matching (``SearchField(partial_match=True)``) is not supported
  18. - ``SearchField(boost=…)`` is only partially respected as PostgreSQL only supports four different boosts.
  19. So if you use five or more distinct values for the boost in your site, slight inaccuracies may occur.
  20. - When :ref:`wagtailsearch_specifying_fields`, the index is not used,
  21. so it will be slow on huge sites.
  22. - Still when :ref:`wagtailsearch_specifying_fields`, you cannot search
  23. on a specific method.
  24. Installation
  25. ============
  26. Add ``'wagtail.contrib.postgres_search',`` anywhere in your ``INSTALLED_APPS``:
  27. .. code-block:: python
  28. INSTALLED_APPS = [
  29. ...
  30. 'wagtail.contrib.postgres_search',
  31. ...
  32. ]
  33. Then configure Wagtail to use it as a search backend.
  34. Give it the alias `'default'` if you want it to be the default search backend:
  35. .. code-block:: python
  36. WAGTAILSEARCH_BACKENDS = {
  37. 'default': {
  38. 'BACKEND': 'wagtail.contrib.postgres_search.backend',
  39. },
  40. }
  41. After installing the module, run ``python manage.py migrate`` to create the necessary ``postgres_search_indexentry`` table.
  42. You then need to index data inside this backend using
  43. the :ref:`update_index` command. You can reuse this command whenever
  44. you want. However, it should not be needed after a first usage since
  45. the search engine is automatically updated when data is modified.
  46. To disable this behaviour, see :ref:`wagtailsearch_backends_auto_update`.
  47. Configuration
  48. =============
  49. Language / PostgreSQL search configuration
  50. ------------------------------------------
  51. Use the additional ``'SEARCH_CONFIG'`` key to define which PostgreSQL
  52. search configuration should be used. For example:
  53. .. code-block:: python
  54. WAGTAILSEARCH_BACKENDS = {
  55. 'default': {
  56. 'BACKEND': 'wagtail.contrib.postgres_search.backend',
  57. 'SEARCH_CONFIG': 'english',
  58. }
  59. }
  60. As you can deduce, a PostgreSQL search configuration is mostly used to define
  61. rules for a language, English in this case. A search configuration consists
  62. in a compilation of algorithms (parsers & analysers)
  63. and language specifications (stop words, stems, dictionaries, synonyms,
  64. thesauruses, etc.).
  65. A few search configurations are already defined by default in PostgreSQL.
  66. You can list them using ``sudo -u postgres psql -c "\dF"`` in a Unix shell
  67. or by using this SQL query: ``SELECT cfgname FROM pg_catalog.pg_ts_config``.
  68. These already-defined search configurations are decent, but they’re basic
  69. compared to commercial search engines.
  70. If you want better support for your language, you will have to create
  71. your own PostgreSQL search configuration. See the PostgreSQL documentation for
  72. `an example <https://www.postgresql.org/docs/current/static/textsearch-configuration.html>`_,
  73. `the list of parsers <https://www.postgresql.org/docs/current/static/textsearch-parsers.html>`_,
  74. and `a guide to use dictionaries <https://www.postgresql.org/docs/current/static/textsearch-dictionaries.html>`_.
  75. Atomic rebuild
  76. --------------
  77. Like the Elasticsearch backend, this backend supports
  78. :ref:`wagtailsearch_backends_atomic_rebuild`:
  79. .. code-block:: python
  80. WAGTAILSEARCH_BACKENDS = {
  81. 'default': {
  82. 'BACKEND': 'wagtail.contrib.postgres_search.backend',
  83. 'ATOMIC_REBUILD': True,
  84. }
  85. }
  86. This is nearly useless with this backend. In Elasticsearch, all data
  87. is removed before rebuilding the index. But in this PostgreSQL backend,
  88. only objects no longer in the database are removed. Then the index is
  89. progressively updated, with no moment where the index is empty.
  90. However, if you want to be extra sure that nothing wrong happens while updating
  91. the index, you can use atomic rebuild. The index will be rebuilt, but nobody
  92. will have access to it until reindexing is complete. If any error occurs during
  93. the operation, all changes to the index are reverted
  94. as if reindexing was never started.