How to Use Full-Text Search in PostgreSQL

In this tutorial we are going to explain how to use Full-Text Search in PostgreSQL on Linux Cloud server.

1st Step: Creating Example Data

To begin, we'll need a few information to test the full-text search module with, so how about we make some example information. In the event that you have your own table with text values as of now, you can skip to 2nd Step and make suitable substitutions while following along.

Something else, the first step is to associate with the PostgreSQL database from its Linux Cloud server. Since you are associating from a similar host, of course, you won't have to enter your password.


cloud server price in India

 

$ sudo -u postgres psql john

Now, create a example table in the database called info. Every section in this table will speak to a info article with a title, some substance, and the writer's name alongside a special identifier.

john=# CREATE TABLE info(

john=#  id SERIAL PRIMARY KEY,

john=#  title TEXT NOT NULL,

john=#  content TEXT NOT NULL,

john=#  author TEXT NOT NULL

john=# );

 

Now, put some example information to the table utilizing the INSERT command. This illustration information in the command below speaks to some example info articles.

john=# INSERT INTO info (id, title, content, author) VALUES

john=#   (1, 'Pacific Northwest high-speed rail line', 'Currently there are only a few options for traveling the 140 miles between Seattle and Vancouver and none of them are ideal.', 'Greg'),

john=#   (2, 'Hitting the beach was voted the best part of life in the region', 'Exploring tracks and trails was second most popular, followed by visiting the shops and then checking out local parks.', 'Ethan'),

john=#   (3, 'Machine Learning from scratch', 'Bare bones implementations of some of the foundational models and algorithms.', 'Jo');

 

2nd Step: Preparing and Searching Documents

The initial step here is building one document with various content segments from the database table. At that point, we can change the subsequent string into a vector of words, which is the thing that we'll use in the inquiries.

johndb=# \x

Result

Expanded display is on.

 

To begin with, we'll have to assemble every one of the segments utilizing the PostgreSQL concatenate function || and change work to_tsvector().

john=# SELECT title || '. ' || content as document, to_tsvector(title || '. ' || content) as metadata FROM news WHERE id = 1;


cloud server for Linux cloud server for windows

3rd Step: Improving FTS Performance

Creating an archive each time we utilize a FTS inquiry can turn into an execution issue when utilizing huge datasets or littler Linux Cloud servers. One great answer for this, which we'll execute here, is to produce the changed report while inserting the line and store it alongside the other information. Along these lines, we can simply recover it with an inquiry as opposed to generating it without fail.

To begin with, make an additional segment called document to the current info table.

john=# ALTER TABLE info ADD "document" tsvector;

We'll currently need to utilize an alternate question to insert information into the table. Not at all like 2nd Step, here we'll likewise need to set up the changed report and include it into the new documentsection, this way:

john=# INSERT INTO news (id, title, content, author, document)

john=# VALUES (4, 'Sleep deprivation curing depression', 'Clinicians have long known that there is a strong link between sleep, sunlight and mood.', 'Patel', to_tsvector('Sleep deprivation curing depression' || '. ' || 'Clinicians have long known that there is a strong link between sleep, sunlight and mood.'));

 

Adding another column to the current table expects us to include exhaust esteems for the archive segment at first. Presently we have to refresh it with the created values.

Utilize the UPDATE command to include the missing data.

john=# UPDATE info SET document = to_tsvector(title || '. ' || content) WHERE document IS NULL;

At last, indexes enable the database to discover pushes quicker via seeking utilizing exceptional information structures and calculations. PostgreSQL has a few sorts of lists which are suited to specific kinds of inquiries. The most significant ones for this utilization case are GiST files and GIN files. The fundamental contrast between them is the manner by which quick they can recover records from the table. GIN is slower to build while including new information, yet quicker to query; GIST assembles speedier, yet requires extra information reads.

Since GiST is around 3 times slower to recover information than GIN, we'll make a GIN index here.

John =# CREATE INDEX idx_fts_search ON info USING gin(document);

When you're set, you can leave the database console using \q.