Skip site navigation (1) Skip section navigation (2)


From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Simon Riggs <simon(at)2ndquadrant(dot)com>,PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Date: 2013-01-15 16:08:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Claudio Freire (klaussfreire(at)gmail(dot)com) wrote:
> Postgres' packetized protocol lends itself quite well for this kind of
> thing. It could even be done on a packet-by-packet basis. The only
> drawback I see, is that it pretty much rules out piping through
> arbitrary commands (a protocol needs to be very clearly defined).

Actually, wouldn't PG's packet-based protocol be exactly the wrong way
to do any kind of good on-the-wire compression?  You certainly wouldn't
want to waste time compressing small packets, such as a single INSERT
command or similar, as you'll always have to send a packet out anyway.
Even doing it at the protocol level with something ssl-like, where
you wrap the entire connection, wouldn't help if the client has a
process along the lines of:

send INSERT command
wait for response
send INSERT command
wait for response

Since you'd still have to flush after each small bit of data.

Where it does work well is when you move into a bulk-data mode (ala
COPY) and can compress relatively large amounts of data into a smaller
number of full-size packets to be sent.



In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-15 16:10:22
Subject: Re: logical changeset generation v4
Previous:From: Tom LaneDate: 2013-01-15 16:06:44
Subject: Re: pg_ctl idempotent option

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group