Re: plpgsql performance - SearchCatCache issue

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: plpgsql performance - SearchCatCache issue
Date: 2011-06-19 11:29:49
Message-ID: BANLkTimchyDP8C3Ed0ASAT=uVMXWQLxz+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/6/19 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 2011/6/19 Robert Haas <robertmhaas(at)gmail(dot)com>:
>> On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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.

Using a cache for these values increased speed about 30% - I'll
prepare patch to next commitfest.

Regards

Pavel Stehule

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2011-06-19 11:40:28 Re: [v9.2] DROP Reworks Part.0 - 'missing_ok' support of get_object_address
Previous Message Noah Misch 2011-06-19 11:10:42 Re: Identifying no-op length coercions