| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Don't deform column-by-column in composite_to_json |
| Date: | 2019-02-01 23:21:16 |
| Message-ID: | 20190201232116.6zil5sqmdxg4ndm4@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
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.
Greetings,
Andres Freund
| Attachment | Content-Type | Size |
|---|---|---|
| faster_composite_to_json.diff | text/x-diff | 1.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2019-02-01 23:57:27 | Re: DNS SRV support for LDAP authentication |
| Previous Message | Chengchao Yu | 2019-02-01 23:12:39 | RE: [PATCH] Fix Proposal - Deadlock Issue in Single User Mode When IO Failure Occurs |