Home/ Questions/Q 8802071
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-14T00:59:44+00:00

Somehow I’ve tricked myself into writing a full text search implementation on a database.

  • 0

Somehow I’ve tricked myself into writing a full text search implementation on a database. I have a table that represents all the entities in my database, a table that represents all the tags, and a table representing the many to many relationship of tags to entities.

I wrote a query that groups all tag names for a given entity and concatenates them into a string, which I then transform into a ts_vector. That query looks like this:

SELECT e.id, to_tsvector(c.publicname || ' ' || string_agg(cv.name, ' '))
FROM categoryvalue cv, entitycategoryvalue ecv, entity e 
WHERE ccv.categoryvalueid = cv.id AND e.id = ecv.entityid
GROUP BY e.id;

The query returns results in this schema:

id | to_tsvector
1  | tag_a, tag_b, tag_c
2  | tag_b, tag_d, tag_e

Which is exactly what I’d like to match a ts_query against. I’m a noob at SQL though, and I am wondering if there is a way I can create a table that is continually updated with the results of the query I’ve written?

EDIT: I documented my eventual solution and system in this blog post http://tech.pro/tutorial/1142/building-faceted-search-with-postgresql

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think you want a VIEW.

    CREATE VIEW my_tsearch_table AS
SELECT e.id, to_tsvector(c.publicname || ' ' || string_agg(cv.name, ' '))
FROM categoryvalue cv, entitycategoryvalue c=ecv, entity e 
WHERE ccv.categoryvalueid = cv.id AND e.id = ecv.celebrityid
GROUP BY e.id;

    Note, however, that you cannot add indexes to a view. This may be a problem with full-text search, as it’s quite expensive to generate all those tsvectors for every search.

    If you need to index that table, you are looking for a materialized view.

    PostgreSQL does not support automatically maintained materialized views; you can’t just CREATE MATERIALIZED VIEW and then add some indexes to it.

    What you can do is manually maintain a materialized view using an ordinary table, an ordinary view created with your query, and some trigger functions.

    Add a trigger function on each table that contributes to the view, and have that trigger function update (or insert into, or delete from, as appropriate) the materialized view based on updates made to that table. This can be complicated to get right in a concurrent environment, though, and it can be prone to lock-ordering deadlocks.

    An alternative to a trigger-maintained view is to live with the materialized view getting a little out of date. Periodically create a new table, copy your ordinary view into the new table, add the desired indexes, then drop the old materialized view table and rename the new one to replace it.

    See also:

    • 0