Re: plpgsql performance - SearchCatCache issue

2011/6/19 Robert Haas <robertmhaas@gmail.com>:
> On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> Is this profile expected?
>
> I've certainly seen profiles before where the catcache overhead was
> significant.  I don't think that I've seen SearchCatCache() quite this
> high on any of the profiling I've done, but then again I don't tend to
> profile the same things you do, so maybe that's not surprising.  I
> think the interesting question is probably "where are all those calls
> coming from?" and "can we optimize any of them away?" rather than "how
> do we make SearchCatCache() run faster?".   I would be willing to bet
> money that the latter is largely an exercise in futility.

I would not to attack on SearchCatCache. This is relative new area for
me, so I just asked.

The "suspect" part should be inside exec_assign_value
               case PLPGSQL_DTYPE_ARRAYELEM:                       {
        ....
                               /* Fetch current value of array datum */
exec_eval_datum(estate,target, 

&arraytypeid, &arraytypmod,

&oldarraydatum, &oldarrayisnull);
                               /* If target is domain over array,
reduce to base type */                               arraytypeid =
getBaseTypeAndTypmod(arraytypeid, &arraytypmod);
                               /* ... and identify the element type */                               arrayelemtypeid =
get_element_type(arraytypeid);                              if (!OidIsValid(arrayelemtypeid))
           ereport(ERROR, 

(errcode(ERRCODE_DATATYPE_MISMATCH),

errmsg("subscripted object is not an array")));
                               get_typlenbyvalalign(arrayelemtypeid,
 &elemtyplen,
 &elemtypbyval,
 &elemtypalign);                               arraytyplen = get_typlen(arraytypeid);


so any update of array means a access to CatCache.

These data should be cached in some referenced data type info
structure and should be accessed via new exec_eval_array_datum()
function.

Regards

Pavel Stehule


>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>