Re: cache type info in json_agg and friends - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: cache type info in json_agg and friends
Date
Msg-id 55F72D0D.3010003@dunslane.net
Whole thread Raw
In response to Re: cache type info in json_agg and friends  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: cache type info in json_agg and friends  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers

On 09/14/2015 03:42 PM, Teodor Sigaev wrote:
>> Currently, json_agg, jsonb_agg, json_object_agg and jsonb_object_agg do
>> type classification on their arguments on each call to the transition
>> function. This is quite unnecessary, as the argument types won't change.
>> This patch remedies the defect by caching the necessary values in the
>> aggregate state object.
> +1
>
>>
>> While this doesn't change the performance much, since these functions
>> are essentially dominated by other bits of the processing, I think it is
>> nevertheless worth doing.
> Agree
>
> After quick observation of your patch, why don't you use FmgrInfo 
> instead of JsonAggState.val_output_func/JsonAggState.key_category? 
> FmgrInfo could be filled by fmgr_info_cxt() in aggcontext memory 
> context. Suppose, direct usage of FmgrInfo with FunctionCall a bit 
> faster than OidFunctionCall.


Well, we need the category to help data_to_json(b) do its work. 
Nevertheless, it might be doable to pass an FmgrInfo* to datum_to_json. 
I'll see what I can do.

cheers

andrew




pgsql-hackers by date:

Previous
From: Paul Jungwirth
Date:
Subject: Re: Review: GiST support for UUIDs
Next
From: Robert Haas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Check existency of table/schema for -t/-n option (pg_dump/pg_res