Re: gsoc08, text search selectivity, pg_statistics holding an array of a different type

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 Lin****angas
   EnterpriseDB   http://www.enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers