Re: [HACKERS] Help: fmgr_info: function 0: cache lookup failed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "D'Arcy" "J(dot)M(dot)" Cain <darcy(at)druid(dot)net>
Cc: jwieck(at)debis(dot)com, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Help: fmgr_info: function 0: cache lookup failed
Date: 1999-05-27 13:56:56
Message-ID: 22272.927813416@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"D'Arcy" "J.M." Cain <darcy(at)druid(dot)net> writes:
>>>> I tried just setting oprcanhash to true but that didn't do it. Can
>>>> you suggest what fields I need to look at in pg_operator?
>>
>> oprrest and oprjoin

> OK, I did this and it worked. I'll go work on the documentation now.

OK, I see the problem: btreesel() and friends blithely assume that the
operator used in an index will have a selectivity function (oprrest).

I can see two reasonable fixes:
* Default to an 0.5 estimate if no oprrest link (this is what the
optimizer does for operators that have no oprrest).
* Generate an error message along the lines of "index operators must
have a restriction selectivity estimator", if we think that they
really really oughta.

I'm not sure which way to jump. The former would be more friendly for
people just starting to develop index support for a new data type ...
but then they might never realize that lack of an estimator is hurting
performance for them. Comments?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message D'Arcy J.M. Cain 1999-05-27 13:58:14 New xindex.sgml
Previous Message Michael Meskes 1999-05-27 12:37:25 Re: [HACKERS] Uh-oh II - ecpg