Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sql/pgwire: responses to commands should be coalesced #4549

Closed
knz opened this issue Feb 22, 2016 · 4 comments
Closed

sql/pgwire: responses to commands should be coalesced #4549

knz opened this issue Feb 22, 2016 · 4 comments
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
Milestone

Comments

@knz
Copy link
Contributor

knz commented Feb 22, 2016

Noticed while comparing pg and cockroach network traces, e.g. in #4538 (comment)

The responses to a combined command packet are sent as separate/individual packets by cockroach, whereas pg keeps the responses combined. The extra packets mean more network traffic / overhead.

Responses should be coalesced for performance.

@petermattis petermattis changed the title pgwire: responses to commands should be coalesced sql/pgwire: responses to commands should be coalesced Feb 22, 2016
@petermattis
Copy link
Collaborator

Strange. Looks to me like we only flush the write buffer immediately before trying to read another command from the client.

@petermattis petermattis added the C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) label Feb 22, 2016
@petermattis petermattis added this to the 1.0 milestone Feb 22, 2016
@petermattis
Copy link
Collaborator

Ah, it looks like postgres is trying to read the next command from the client before flushing the response to the previous command. We could certainly do that as well, though it is mildly irritating to do from Go because the I/O is blocking. What we could do is check to see if the read buffer has another command buffered before flushing the response to the previous command.

@bdarnell
Copy link
Contributor

This is what Nagle's algorithm is for. Go's net package turns TCP_NODELAY on by default; maybe we should turn it off? Although it would be good to be able to flush the outgoing buffer before we go into a blocking read.

@knz
Copy link
Contributor Author

knz commented Feb 25, 2016

( While looking at #4036 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
Projects
None yet
Development

No branches or pull requests

3 participants