> On 2 Feb 2019, at 00:21, Andres Freund <and...@anarazel.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
