From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: Don't deform column-by-column in composite_to_json |
Date: | 2019-02-02 00:35:51 |
Message-ID: | E2B7EFEA-B147-407E-8398-3CE1216171F8@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 2 Feb 2019, at 00:21, Andres Freund <andres(at)anarazel(dot)de> wrote:
> In https://postgr.es/m/20190201162404.onngi77f26baem4g%40alap3.anarazel.de
> I noticed that composite_to_json() deforms column-by-column. Given that
> it always processes all columns, that seems quite the waste of resources.
>
> In some quick'n dirty dirty testing this gives a ~4% benefit in a table
> without nulls and varlenas, and ~7% in one with both. I assume that if
> one were to test with a bit wider table the win would be bigger.
>
> A short test shows that it'd be slower to allocate nulls/values with
> palloc rather than using MaxHeapAttributeNumber. Given that only output
> functions are called from within composite_to_json(), I think that's ok.
Nice catch, patch looks good to me. composite_to_jsonb() has the same
construction, processing every attribute. Should it get a similar patch as
this?
cheers ./daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2019-02-02 00:43:38 | Re: Delay locking partitions during query execution |
Previous Message | Thomas Munro | 2019-02-01 23:57:27 | Re: DNS SRV support for LDAP authentication |