Hi Illya,
On Mon, Nov 21, 2022 at 8:50 PM Ilya Gladyshev
<ilya.v.gladyshev@gmail.com> wrote:
>
> Hi everyone,
>
> I have made a patch that introduces support for libpq binary protocol
> in postgres_fdw. The idea is simple, when a user knows that the foreign
> server is binary compatible with the local and his workload could
> somehow benefit from using binary protocol, it can be switched on for a
> particular server or even a particular table.
>
Why do we need this feature? If it's for performance then do we have
performance numbers?
AFAIU, binary compatibility of two postgresql servers depends upon the
binary compatibility of the platforms on which they run. So probably
postgres_fdw can not infer the binary compatibility by itself. Is that
true? We have many postgres_fdw options that user needs to set
manually to benefit from them. It will be good to infer those
automatically as much as possible. Hence this question.
> The patch adds a new foreign server and table option 'binary_format'
> (by default off) and implements serialization/deserialization of query
> results and parameters for binary protocol. I have tested the patch by
> switching foreign servers in postgres_fdw.sql tests to binary_mode, the
> only diff was in the text of the error for parsing an invalid integer
> value, so it worked as expected for the test. There are a few minor
> issues I don't like in the code and I am yet to write the tests and
> docs for it. It would be great to get some feedback and understand,
> whether this is a welcome feature, before proceeding with all of the
> abovementioned.
>
About the patch itself, I see a lot of if (binary) {} else {} block
which are repeated. It will be good if we can add functions/macros to
avoid duplication.
--
Best Wishes,
Ashutosh Bapat