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

Reply via email to