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
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 |