Re: index question

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: index question
Дата
Msg-id CAKFQuwYN-HtR4x79O6EgFbhBk85E4Bh8WhgmKb7Wj1qZc8LLUQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: index question  ("drum.lucas@gmail.com" <drum.lucas@gmail.com>)
Ответы Re: index question  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-general
On Sun, May 1, 2016 at 7:27 PM, drum.lucas@gmail.com <drum.lucas@gmail.com> wrote:

​Repeating the query to improve the self-containment aspect of the email would have been appreciated.

if possible please have a look on the explain analyze results:


What else can I do?

The indexes I created is:
- CREATE INDEX CONCURRENTLY ix_inode_segments_notes_clientids2 ON gorfs.inode_segments USING btree ("full_path");

 
​the only condition that could even potentially use this index​ is:

s.full_path ~ '/userfiles/account/[0-9]+/[a-z]+/[0-9]+'

My knowledge is limited in this area, and the documentation covers this specific dynamic only minimally, but for certain attempting to perform an un-anchored regexp match using a btree index is impossible.

These leaves to avenues to explore.

1) See if a start-of-string anchor will make the btree index usable
2) Use the pg_trgm contrib module


- CREATE INDEX CONCURRENTLY ix_inodes_checksum_st_size ON gorfs.inodes USING btree ("checksum_md5","st_size");
This one was used.​

​IMO you are leaving too much infomation encoded in the full_path.  I'd personally setup triggers to parse out the components on insert/update into fields and then index those fields.  In fact I'd probably use some form of inheritance or other one-to-one relationship here.

David J.

В списке pgsql-general по дате отправления:

Предыдущее
От: Yogesh Sharma
Дата:
Сообщение: Re: Issue during postgresql startup
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: index question