Re: Extensibility of the PostgreSQL wire protocol - Mailing list pgsql-hackers

From Damir Simunic
Subject Re: Extensibility of the PostgreSQL wire protocol
Date
Msg-id F3992ECD-91C5-4FA3-B261-7D17318BCAAD@gmail.com
Whole thread Raw
In response to Re: Extensibility of the PostgreSQL wire protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Extensibility of the PostgreSQL wire protocol  (Heikki Linnakangas <hlinnaka@iki.fi>)
List pgsql-hackers
> On 11 Feb 2021, at 16:06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Maybe there is some useful thing that can be accomplished here, but we
> need to consider the bigger picture rather than believing (without proof)
> that a few hook variables will be enough to do anything.
>
>             regards, tom lane
>

Pluggable wire protocol is a game-changer on its own.

The bigger picture is that a right protocol choice enables large-scale architectural simplifications for whole classes
ofproduction applications. 

For browser-based applications (lob, saas, e-commerce), having the database server speak the browser protocol enables
architectureswithout backend application code. This in turn leads to significant reductions of latency, complexity, and
applicationdevelopment time. And it’s not just lack of backend code: one also profits from all the existing
infrastructurelike per-query compression/format choice, browser connection management, sse, multiple streams,
prioritization,caching/cdns, etc. 

Don’t know if you’d consider it as a proof, yet I am seeing 2x to 4x latency reduction in production applications from
protocolconversion to http/2. My present solution is a simple connection pooler I built on top of Nginx transforming
thetcp stream as it passes through. 

In a recent case, letting the browser talk directly to the database allowed me to get rid of a ~100k-sloc .net backend
andall the complexity and infrastructure that goes with coding/testing/deploying/maintaining it, while keeping all the
positives:per-query compression/data conversion, querying multiple databases over a single connection, session cookies,
etc.Deployment is trivial compared to what was before. Latency is down 2x-4x across the board. 

Having some production experience with this approach, I can see how http/2-speaking Postgres would further reduce
latency,processing cost, and time-to-interaction for applications. 

A similar case can be made for IoT where one would want to plug an iot-optimized protocol. Again, most of the benefit
ispossible with a protocol-converting proxy, but there are additional non-trivial performance gains to be had if the
databaseserver speaks the right protocol. 

While not the only use cases, I’d venture a guess these represent a sizable chunk of what Postgres is used for today,
andwill be used even more for, so the positive impact of a pluggable protocol would be significant. 

--
Damir


pgsql-hackers by date:

Previous
From: Amul Sul
Date:
Subject: Re: [Patch] ALTER SYSTEM READ ONLY
Next
From: Markus Wanner
Date:
Subject: [PATCH] Present all committed transaction to the output plugin