Please define PQ_BUFFER_SIZE in interfaces/libpq/fe-misc.c
Hi,
I am accelerating the transfer of resultset
from backend to client using the zlib library.
While coding, I was surprised that
magic number 8192 (which is defined as PQ_BUFFER_SIZE in
backend/libpq/pqcomm.c) are written into the code
in interfaces/libpq/fe-misc.
I thought the magic number should be eliminated.
So I defined the magic number 8192 as PQ_BUFFER_SIZE in fe-misc.c.
The result is attached to this mail.
# it is just a slight modification
I am very happy if you accept my proposition.
Best regards,
-- Hideyuki Kawashima
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Hideyuki KAWASHIMA <kawasima@ayu.ics.keio.ac.jp> Ph.D.
Research Associate, Keio University
Attachments:
fe-misc.ctext/plain; charset=us-asciiDownload
Hideyuki Kawashima <kawasima@ayu.ics.keio.ac.jp> writes:
While coding, I was surprised that
magic number 8192 (which is defined as PQ_BUFFER_SIZE in
backend/libpq/pqcomm.c) are written into the code
in interfaces/libpq/fe-misc.
AFAICS the uses of 8192 in fe-misc.c have no relationship to
PQ_BUFFER_SIZE or indeed much of anything. They are just arbitrary
amounts by which to increase the I/O buffer size.
Of course they are not *completely* arbitrary --- they are essentially
guesses about the buffering behavior of the kernel and TCP stack.
But they have nothing to do with the server-side PQ_BUFFER_SIZE.
The result is attached to this mail.
In future please submit proposed changes as "diff -c" patches.
A complete file is useless because it cannot be applied without
risking overwriting other people's changes.
regards, tom lane
Thanks for teaching me about 8192 in fe-misc.c.
I recognized the 8192 in fe-misc.c does not relate to PQ_BUFFER_SIZE
in pqcomm.c, but I am pleased if someone revises the magic number.
And I am sorry for my incorrect format patch.
From next time, I will submit my proposition as "diff -c" patches.
-- Hideyuki Kawashima