Re: libpq sendQuery -- getResult not returning until all queries complete
От | Kelly Burkhart |
---|---|
Тема | Re: libpq sendQuery -- getResult not returning until all queries complete |
Дата | |
Msg-id | AANLkTinm5KR0ULFFZ8P-4MOsHv5_t-G_UZVzwsqFKKAL@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: libpq sendQuery -- getResult not returning until all queries complete (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: libpq sendQuery -- getResult not returning until all
queries complete
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: