2011/6/19 Pavel Stehule :
> 2011/6/19 Robert Haas :
>> On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule
>> 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
2011/6/19 Robert Haas :
> On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule
> 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,
On Sat, Jun 18, 2011 at 9:21 AM, Pavel Stehule 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
profi
Hello
I tried to optimize repeated assign in plpgsql with elimination
unnecessary palloc/free calls.
I tested changes on simple bublesort
postgres=# \sf buble
CREATE OR REPLACE FUNCTION public.buble(integer[])
RETURNS integer[]
LANGUAGE plpgsql
AS $function$
declare
unsorted bool := true;
