On Thu, Aug 6, 2015 at 03:15 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Wed, Aug 5, 2015 at 11:53 PM, Bruce Momjian br...@momjian.us wrote:
On Wed, Jul 8, 2015 at 12:24:37PM -0400, Robbie Harwood wrote:
You update the documentation just for psql but your change effects any
Kevin Wooten kd...@me.com wrote:
On Nov 4, 2014, at 12:55 AM, Craig Ringer cr...@2ndquadrant.com wrote:
I have to say I like some aspects of how pgjdbc-ng is being done - in
particular use of Maven and being built around non-blocking I/O.
OTOH, the use of Google Guava I find pretty
Craig Ringer wrote:
On 11/02/2014 09:27 PM, Mikko Tiihonen wrote:
Is the following summary correct:
- the network protocol supports pipelinings
Yes.
All you have to do is *not* send a Sync message and be aware that the
server will discard all input until the next Sync, so pipelining
From: Andres Freund and...@2ndquadrant.com
On 2014-11-01 14:04:05 +, Mikko Tiihonen wrote:
I created a proof of concecpt patch for postgresql JDBC driver that
allows the caller to do pipelining of requests within a
transaction. The pipelining here means same as for HTTP: the client
From: Andres Freund and...@2ndquadrant.com
On 2014-11-01 14:04:05 +, Mikko Tiihonen wrote:
I created a proof of concecpt patch for postgresql JDBC driver that
allows the caller to do pipelining of requests within a
transaction. The pipelining here means same as for HTTP
Mon Sep 17 00:00:00 2001
From: Mikko Tiihonen mikko.tiiho...@nitorcreations.com
Date: Sat, 1 Nov 2014 15:43:19 +0200
Subject: [PATCH] Example pipelined single-shot query
---
org/postgresql/core/QueryExecutor.java | 13 +++
org/postgresql/core/v2/QueryExecutorImpl.java | 5 +
org
Hi,
Currently the criteria on updating the F/B protocol is undefined. This makes it
hard to update the protocol going forward. It makes it also hard to write
library/driver/application implementations that will be more future proof to
future server versions.
Ideally the documentation for 9.4
On 12/13/2012 12:19 AM, Peter Geoghegan wrote:
On 12 December 2012 22:11, Mikko Tiihonen
mikko.tiiho...@nitorcreations.com wrote:
noticed a XXX: It might be worth considering using an atomic fetch-and-add
instruction here, on architectures where that is supported. in lock.c
Here is my first
On 12/14/2012 05:55 PM, Merlin Moncure wrote:
On Fri, Dec 14, 2012 at 9:33 AM, Mikko Tiihonen
mikko.tiiho...@nitorcreations.com wrote:
On 12/13/2012 12:19 AM, Peter Geoghegan wrote:
On 12 December 2012 22:11, Mikko Tiihonen
mikko.tiiho...@nitorcreations.com wrote:
noticed a XXX: It might
,%rax
dd1: f0 83 2c 02 01 lock subl $0x1,(%rdx,%rax,1)
dd6: f3 c3 repz retq
dd8: 0f 1f 84 00 00 00 00nopl 0x0(%rax,%rax,1)
ddf: 00
From 958b04eb08603167dee2fe6684f9430f5b578f28 Mon Sep 17 00:00:00 2001
From: Mikko Tiihonen
On 01/25/2012 06:40 PM, Tom Lane wrote:
Marko Kreenmark...@gmail.com writes:
On Wed, Jan 25, 2012 at 10:23:14AM -0500, Tom Lane wrote:
Huh? How can that work? If we decide to change the representation of
some other well known type, say numeric, how do we decide whether a
client setting that
Previous title was: Add minor version to v3 protocol to allow changes without
breaking backwards compatibility
On 01/20/2012 04:45 AM, Noah Misch wrote:
On Thu, Jan 19, 2012 at 02:00:20PM -0500, Robert Haas wrote:
On Thu, Jan 19, 2012 at 10:37 AM, Noah Mischn...@leadboat.com wrote:
I agree
On 11/30/2011 06:52 PM, Merlin Moncure wrote:
On Mon, Nov 28, 2011 at 9:18 AM, Mikko Tiihonen
mikko.tiiho...@nitorcreations.com wrote:
Hi,
As discussed few days ago it would be beneficial if we could change the v3
backend-client protocol without breaking backwards compatibility.
Here
, but the client only requests 21,23. The server must inform back that combination
21,23 is reduced to 21. And if then the client can not support 21 without 23 the final feature set will not contain 21 or 23.
-Mikko
commit d7ef5f1aef0941ec4b931f24745b65d77e7511e4
Author: Mikko Tiihonen mikko.tiiho
On 11/24/2011 02:36 AM, Kevin Grittner wrote:
Oliver Jowett wrote:
Can we get a mechanism for minor protocol changes in this future
version? Something as simple as exchanging a list of protocol
features during the initial handshake (then use only features that
are present on both sides) would
Hi,
During conversion of the jdbc driver to use binary encoding when receiving
array objects from postgres it was noticed
that for example for int[] arrays the binary encoding is normally 30% to 200%
larger in bytes than the text encoding.
This was of concern to some users with slower links
16 matches
Mail list logo
