From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Jan Urbański <j(dot)urbanski(at)students(dot)mimuw(dot)edu(dot)pl> |
Cc: | "Postgres - Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: gsoc08, text search selectivity, pg_statistics holding an array of a different type |
Date: | 2008-05-09 20:11:08 |
Message-ID: | 4824AFDC.7070804@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-05-09 20:25:34 | Re: constraint exclusion analysis caching |
Previous Message | Bruce Momjian | 2008-05-09 20:07:57 | Re: psql wrapped format default for backslash-d commands |