Re: ANALYZE versus expression indexes with nondefault opckeytype

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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 column contents (indeed
>> cannot, since our index AMs provide no API for extracting the contents),

> I don't think it'll be an issue, but just in case- is there any reason
> this will cause trouble for the possible index-only quals/scans work?

Not that I can see. What ANALYZE and the planner want to do is provide
stats on the behavior of the indexed expression. The fact that certain
index opclasses don't actually store that value is of no interest. Even
if it did become of interest later on, we're under no compulsion to not
redefine the contents of pg_statistic when we need to.

>> So that seems to make it not practical to back-patch.

> But we could get it into 9.0..

Hmm. I was thinking it was a bit late for 9.0 too, since it'd
invalidate any testing anyone's done of their custom typanalyze
functions. However, since we're still only in beta, maybe that's
acceptable.

>> Comments? I'm not sure which way to jump here.

> For my 2c- let's get it fixed for 9.0 cleanly and encourage people who
> run into this to upgrade to that once it's released. Perhaps I've
> missed it, but I don't recall seeing many complaints about this.

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 realized they were missing something.
But it would be nice to have this working in 8.4, and I'll be quite
unhappy if we don't have it in 9.0.

If people feel it's not too late for an ABI break in 9.0 then I'm
willing to compromise on backpatching the "clean" fix. I'm not entirely
convinced it's that much cleaner than the hack solution though.

regards, tom lane