Re: WIP: Generic functions for Node types using generated metadata - Mailing list pgsql-hackers

From David Rowley
Subject Re: WIP: Generic functions for Node types using generated metadata
Date
Msg-id CAApHDvoO+=6xzB5YKAZ1BYxSNo0GEN904O0gC+0LQt+aabajWQ@mail.gmail.com
Whole thread Raw
In response to Re: WIP: Generic functions for Node types using generated metadata  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Fri, 20 Sep 2019 at 17:19, Andres Freund <andres@anarazel.de> wrote:
> 3) WIP: Improve and expand stringinfo.[ch].
>
>    Expands the set of functions exposed, to allow appending various
>    numeric types etc. Also improve efficiency by moving code to inline
>    functions - that's beneficial because the size is often known, which
>    can make the copy faster.

I've thought it might be useful to have appendStringInfoInt() and the
like before. However, I wondered if there's a good reason that the
format needs to be easily human-readable. We could reduce the size of
the output and speed up read/write functions if we were to use base16
or even base64 output.

I also think the Bitmapset output is pretty inefficient. The output is
optimized for something that Bitmapsets themselves are not optimized
for. The only time the current output will be efficient is if there
are very few set bits but the values of those bits are very far apart.
Bitmapsets themselves are not optimal for that, so I don't see why our
out function for it should be. ISTM it would be better encoded as a
hex string, or perhaps if we still want to optimize a bit for sparse
Bitmapsets then it could be done as word_number:word_value. However,
that would mean the output would be variable depending on the width of
the bitmapword.

David



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: FailedAssertion at ReorderBufferCheckMemoryLimit()
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Read access for pg_monitor to pg_replication_origin_status view