On Tue, Dec 21, 2010 at 6:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Tue, Dec 21, 2010 at 6:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> If you just unconditionally flush there, it will result in an extra
>>> network message in the normal case where there's not another query
>>> to do. The current code is designed not to flush until it sends
>>> ReadyForQuery.
>
>> yeah, I was looking at that. I don't see an easy way to test if there
>> is another query waiting to execute right there. Maybe a
>> documentation patch is in order :-).
>
> dest.c doesn't have the info available. I think that to do this, we'd
> need to move the responsibility for calling pq_flush out to postgres.c.
> Not sure if it's worth it.
So if I understand correctly, a flush will occur when all commands are
completed and prior to completion, whenever PqSendBuffer is full.
Analogous to stdio full vs. line buffering, this is full rather than
result buffering.
It seems to me that is not quite optimal and 'result buffering' would
be better. Did you come to the same conclusion but decide that it's
not 'better enough' to justify polluting postgres.c with a special
flush to satisfy this case?
-K
