Re: Tsearch2 - bad performance with concatenated ts-vectors
От | Robert Haas |
---|---|
Тема | Re: Tsearch2 - bad performance with concatenated ts-vectors |
Дата | |
Msg-id | CA+Tgmobw--pbT_zVWxNNHEzLSnNj7qVhqY9UwqCfvejM-Ob2ow@mail.gmail.com обсуждение исходный текст |
Ответ на | Tsearch2 - bad performance with concatenated ts-vectors (Jan Wielgus <jan_w@tlen.pl>) |
Список | pgsql-performance |
On Tue, Aug 2, 2011 at 2:22 AM, Jan Wielgus <jan_w@tlen.pl> wrote: > So, there is apparently a problem with vector concatenating - the indexes don't work then. I tried to use the vectors separatelyand to make 'OR' comparison between single vector @@ ts_query checks, > but it didn't help very much (performance was better, but still over 20 sec): > ... > (participant.participant_tsv @@ to_tsquery('simple',to_tsquerystring('Abigail'))) OR (person.person_tsv @@ to_tsquery('simple',to_tsquerystring('Abigail'))) > ... > > Is there a way to make this work with better performance? Or is it necessary to create a single vector that contains datafrom multiple tables and then add an index on it? It would be so far problematic for us, > because we are using multiple complex queries with variable number of selected columns. I know that another solution mightbe an union among multiple queries, every of which uses a single vector, > but this solution is inconvenient too. Only something of the form 'indexed-column indexable-operator value' is going to be indexable. So when you concatenate two columns from different tables - as you say - not indexable. In general, OR-based conditions that cross table boundaries tend to be expensive, because they have to be applied only after performing the join. You can't know for sure looking only at a row from one table whether or not it will be needed, so you have to join them all and then filter the results. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-performance по дате отправления: