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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: psql wrapped format default for backslash-d commands
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: constraint exclusion analysis caching