PostgreSQL има няколко типа индекси:B-tree, Hash, GiST, Gin и SP-GiST. Очевидно всеки от тях покрива конкретна нужда. Например, документацията на PostgreSQL казва за GIN индексите:
Така GIN индексите могат да се използват за индексиране на елементите на масив, hstore и т.н.
Но този път ще говорим за един от онези модули contrib, които предоставят повече видове оператори, които могат да се използват с GIN индекси:pg_trgm.
Този модул създава триграми от текстови низове, така че да може да се използва за намиране на прилики. Това позволява на GIN-подобни индекси, които използват класа на оператора gin_trgm_ops, да се използват при LIKE търсения, дори когато заместващият знак '%' е намерен в началото на шаблона за търсене (например:LIKE име '%jaime%').
За да създадете индекс, който може да се използва по този начин, индексът трябва да бъде създаден по следния начин:
CREATE INDEX idx_gin ON table USING GIN (campo_texto gin_trgm_ops);
С индекс като този съм виждал, че заявките намаляват от над 10 секунди до няколко милисекунди; обаче, преди да побързате да създавате тези индекси, нека разгледаме проблемите, които имате.
Помислете за следната заявка "select show_trgm('Jaime Casanova');" Това ни показва триграмите на текстов низ, в този случай 15 триграми. Така че не е трудно да си представим, че този тип индекс нараства много и колкото по-големи са текстовите низове, толкова повече расте индексът (защото ще има повече триграми). Друго очевидно заключение е, че поддържането на този тип индекси може да бъде скъпо, всъщност те могат значително да повлияят на производителността на INSERT и UPDATE, особено ако има няколко от тези индекси в една и съща таблица, за да се намали малко този проблем с техника, наречена fastupdate беше изобретен, който се състои в поддържане на неподреден списък с чакащи. Така че INSERT и UPDATE вместо да вмъкват в основния индекс, те правят това в тази допълнителна структура, докато не настъпи ВАКУУМ или докато чакащият списък стане по-голям от work_mem. Недостатъците са:1) четенето на индекса трябва да чете и тази допълнителна структура, което може да повлияе на производителността на заявката; и 2) INSERT или UPDATE може да доведе до твърде голямо изоставане и следователно ще започне да обработва изоставането, което ще засегне това INSERT или UPDATE и всички други операции, които се случват едновременно в тази таблица.
В заключение; GIN индекс заедно с модула pg_trgm могат значително да подпомогнат изпълнението на някои заявки, но не бива да се злоупотребява с тях, тъй като могат да бъдат нож с две остриета.
