Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-08-01 Thread Tom Lane
I wrote: > Robert Haas writes: >> 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. > OK, I can live with that. I'll take a look at it shortly. Proposed patch attached (compiles, untested as yet).

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-08-01 Thread Tom Lane
Robert Haas writes: > On Sat, Jul 31, 2010 at 11:15 PM, Tom Lane wrote: >> 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-T

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-08-01 Thread Kevin Grittner
Tom Lane wrote: Robert Haas writes: >> I guess I'd appreciate it if someone could explain in more detail >> in what cases we fail to collect stats. > [detailed description] > I don't think this can be claimed to be a corner case. If you set > up an FTS index according to the first alternati

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-08-01 Thread Robert Haas
On Sat, Jul 31, 2010 at 11:15 PM, Tom Lane 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

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-07-31 Thread Tom Lane
Robert Haas writes: > On Sat, Jul 31, 2010 at 9:16 PM, Stephen Frost wrote: >> * Kevin Grittner (kevin.gritt...@wicourts.gov) wrote: >>> Robert Haas  07/31/10 12:33 PM >>> Tom Lane  wrote: > Failing to store stats isn't a bug? Well, it kind of sounds more like you're removing a kno

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-07-31 Thread Robert Haas
On Sat, Jul 31, 2010 at 9:16 PM, Stephen Frost wrote: > * Kevin Grittner (kevin.gritt...@wicourts.gov) wrote: >> Robert Haas  07/31/10 12:33 PM >>> >> > Tom Lane  wrote: >> >> Failing to store stats isn't a bug? >> > >> > Well, it kind of sounds more like you're removing a known >> > limitation th

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-07-31 Thread Stephen Frost
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote: > Robert Haas 07/31/10 12:33 PM >>> > > Tom Lane wrote: > >> Failing to store stats isn't a bug? > > > > Well, it kind of sounds more like you're removing a known > > limitation than fixing a bug. > > It's operating as designed and document

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-07-31 Thread Kevin Grittner
Robert Haas 07/31/10 12:33 PM >>> > Tom Lane wrote: >> Robert Haas writes: >>> I think this whole discussion is starting with the wrong premise. >>> This is not a bug fix; therefore, it's 9.1 material. >> >> Failing to store stats isn't a bug? > > Well, it kind of sounds more like you're removi

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-07-31 Thread Robert Haas
On Sat, Jul 31, 2010 at 12:06 PM, Tom Lane wrote: > Robert Haas writes: >> I think this whole discussion is starting with the wrong premise. This >> is not a bug fix; therefore, it's 9.1 material. > > Failing to store stats isn't a bug? Well, it kind of sounds more like you're removing a known l

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-07-31 Thread Tom Lane
Robert Haas writes: > I think this whole discussion is starting with the wrong premise. This > is not a bug fix; therefore, it's 9.1 material. Failing to store stats isn't a bug? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-07-31 Thread Robert Haas
On Jul 31, 2010, at 11:00 AM, Tom Lane wrote: > It's only been very recently that we had any useful stats capability > that could apply in such situations (in fact I think we still haven't > actually shipped a non-bogus version of tsvector typanalyze :-(). > So I'm not sure anyone would have reali

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-07-31 Thread Tom Lane
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> After a bit of study of the code, it appears to me that it's not too >> difficult to fix: we just have to use the expression's result type >> rather than the index column's atttypid in the subsequent processing. >> ANALYZE never act

Re: [HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-07-31 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > After a bit of study of the code, it appears to me that it's not too > difficult to fix: we just have to use the expression's result type > rather than the index column's atttypid in the subsequent processing. > ANALYZE never actually looks at the index colu

[HACKERS] ANALYZE versus expression indexes with nondefault opckeytype

2010-07-30 Thread Tom Lane
I've been poking at the FTS problem example recently submitted by Artur Dabrowski. It contains an index declared like so: CREATE INDEX idx_keywords_ger ON search_tab USING gin (to_tsvector('german'::regconfig, keywords)); which can be queried like so select * from search_tab where to_