I wrote:
> The solution I'm considering is to add an additional namespace.c routine
> defined like
> Oid OpnameGetOprid(List *opname, Oid oprleft, Oid oprright)
I coded this up, and it seems to be a win just on code cleanliness
grounds, because there are several places that want to do a search for
an operator with exact input types given; this routine fits their
needs exactly while OpernameGetCandidates was a poor fit. It seems to
behave as advertised in terms of getting rid of OpernameGetCandidates
overhead in the exact-match case --- this only makes for a few percent
overall improvement in the test case I'm looking at, but that's about
what's expected.
I made a non-exact-match test case by changing char(N) to varchar(N)
in the table definitions, and what I see is
samples % symbol name
189998 11.9853 SearchCatCache
68888 4.3455 AllocSetAlloc
66793 4.2134 hash_search
49284 3.1089 OpernameGetCandidates
46472 2.9315 base_yyparse
28268 1.7832 LWLockAcquire
27487 1.7339 DirectFunctionCall1
27071 1.7077 DLMoveToFront
26375 1.6638 nocachegetattr
24956 1.5743 SearchSysCache
21461 1.3538 base_yylex
20176 1.2727 heap_getsysattr
19466 1.2279 FunctionCall2
18148 1.1448 CatalogCacheComputeHashValue
17608 1.1107 _bt_compare
16606 1.0475 MemoryContextAllocZeroAligned
...
6870 0.4334 SearchCatCacheList
This case is significantly slower than the other one anyway, and the
reason is evidently a lot more SearchCatCache calls. AFAICT those
can all be blamed on the getBaseType() calls that are sprinkled through
parse_func.c and parse_oper.c. I thought those would probably come back
to haunt us from a performance standpoint someday :-(
Anyway, I can't measure any performance difference in the
non-exact-match case. Maybe if we got rid of the getBaseType calls
it'd be worth checking again, but for now this seems like a win.
I'll go ahead and commit it.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
