Re: ANALYZE versus expression indexes with nondefault opckeytype
От | Robert Haas |
---|---|
Тема | Re: ANALYZE versus expression indexes with nondefault opckeytype |
Дата | |
Msg-id | AANLkTikYNczTJ6tEYYpcX9PVMCiG4KQZTG8CwO_3z-yk@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ANALYZE versus expression indexes with nondefault opckeytype (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ANALYZE versus expression indexes with nondefault opckeytype
|
Список | pgsql-hackers |
On Sat, Jul 31, 2010 at 11:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Now, of the above the only cases where we'd be likely to be able to do > anything very useful with stats on the expression value are the name > case, which isn't that exciting in practice, and the tsvector cases. > For tsvector it was only with 8.4 that we had non-toy stats code, so > while the limitation is ancient it's only recently that it started to be > meaningful. > > I don't think this can be claimed to be a corner case. If you set up > an FTS index according to the first alternative offered in > > http://developer.postgresql.org/pgdocs/postgres/textsearch-tables.html#TEXTSEARCH-TABLES-INDEX > > you will find that the system fails to collect stats for it and so you > get stupid default estimates for your FTS queries. If this were a > "documented" limitation I'd expect to see a big red warning there to > *not* do it that way. The only way that you actually get usable > tsvector stats at the moment is to explicitly store the tsvector as an > ordinary column, as in the second approach offered in the above > documentation section. Yeah, maybe you're right. But I'd still prefer to see us break the ABI and do this just in 9.0 rather than changing 8.4. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: