Re: gsoc08, text search selectivity, pg_statistics holding an array of a different type
От | Heikki Linnakangas |
---|---|
Тема | Re: gsoc08, text search selectivity, pg_statistics holding an array of a different type |
Дата | |
Msg-id | 4824AFDC.7070804@enterprisedb.com обсуждение исходный текст |
Ответ на | gsoc08, text search selectivity, pg_statistics holding an array of a different type (Jan Urbański <j.urbanski@students.mimuw.edu.pl>) |
Ответы |
Re: gsoc08, text search selectivity, pg_statistics holding an array of a different type
|
Список | pgsql-hackers |
Jan Urbański wrote: > I've been fooling around my GSoC project, and here's the first version > I'm not actually ashamed of showing. Oh, wow, at this speed you'll be done before the summer even starts ;-) > There's one fundamental problem I came across while writing a typanalyze > function for tsvectors. > update_attstats() constructs an array that's later inserted into the > appropriate stavaluesN for a given relation attribute. However, it > assumes that the elements of that array will be of the same type as > their corresponding attribute. Yep, those stavalues fields are quite a hack... > It is no longer true with the design that I planned to use. The > typanalyze function for the tsvector type returns an array of > most-frequent lexemes (cstrings actually) from the tsvectors, not an > array of tsvectors. The question is: is this approach OK? Should > typanalyze functions be able to communicate the type of their result to > analyze_rel() ? I'm thinking of extending the VacAttrStats structure, so > a typanalyze func could set the proper fields to the proper values.re Hmm. One idea is to store an array of tsvectors, with only one lexeme in each tsvector. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: