Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements
Date
Msg-id 20120125110849.GA20084@gmail.com
Whole thread Raw
In response to Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements
List pgsql-hackers
On Tue, Jan 24, 2012 at 09:33:52PM -0500, Robert Haas wrote:
> Furthermore, while we haven't settled the question of exactly what a
> good negotiation facility would look like, we seem to agree that a GUC
> isn't it.  I think that means this isn't going to happen for 9.2, so
> we should mark this patch Returned with Feedback and return to this
> topic for 9.3.

Simply extending the text/bin flags should be quite
uncontroversial first step.  How to express the
capability in startup packet, I leave to others to decide.

But my proposal would be following:

bit 0     : text/bin
bit 1..15 : format version number, maps to best formats in some           Postgres version.  

It does not solve the resultset problem, where I'd like to say
"gimme well-known types in optimal representation, others in text".  
I don't know the perfect solution for that, but I suspect the
biggest danger here is the urge to go to maximal complexity
immediately.  So perhaps the good idea would simply give one
additional bit (0x8000?) in result flag to say that only
well-known types should be optimized.  That should cover 95%
of use-cases, and we can design more flexible packet format
when we know more about actual needs.

libpq suggestions:
 PQsetformatcodes(bool)   only if its called with TRUE, it starts interpreting   text/bin codes as non-bools.  IOW, we
willbe compatible   with old code using -1 as TRUE.
 

protocol suggestions:
 On startup server sends highest supported text/bin codes, and gives error if finds higher code than supported.
Poolers/proxieswith different server versions in pool will simply give lowest common code out.
 


Small Q&A, to put obvious aspects into writing
----------------------------------------------

* Does that mean we need to keep old formats around infinitely?

Yes.    On-wire formats have *much* higher visibility than
on-disk formats.  Also, except some basic types they are
not parsed in adapters, but in client code.  Libpq offers
least help in that respect.

Basically - changing on-wire formatting is big deal,
don't do it willy-nilly.


* Does that mean we cannot turn on new formats automatically?

Yes.  Should be obvious..


-- 
marko



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: GUC_REPORT for protocol tunables was: Re: Optimize binary serialization format of arrays with fixed size elements
Next
From: Tareq Aljabban
Date:
Subject: Configuring Postgres to Add A New Source File