Re: ANALYZE versus expression indexes with nondefault opckeytype
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, pgsql-hackers@postgresql.org
Date: 2010-08-01T12:54:44Z
Lists: 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