Re: WIP: Generic functions for Node types using generated metadata

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Generic functions for Node types using generated metadata
Date: 2020-06-09 08:27:12
Message-ID: CAApHDvoO+=6xzB5YKAZ1BYxSNo0GEN904O0gC+0LQt+aabajWQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 20 Sep 2019 at 17:19, Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-06-09 08:34:13 Re: Read access for pg_monitor to pg_replication_origin_status view
Previous Message Fujii Masao 2020-06-09 08:26:24 FailedAssertion at ReorderBufferCheckMemoryLimit()