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.

Sign up for GitHub

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

Jump to bottom

Don't flush at each put_copy_data call, but flush at get_result #462

Merged
merged 1 commit into from
Jun 14, 2022
Merged

Don't flush at each put_copy_data call, but flush at get_result #462

merged 1 commit into from
Jun 14, 2022

Commits on Jun 14, 2022

  1. Don't flush at each put_copy_data call, but flush at get_result 

    This better mimics, what libpq does internally.

put_copy_data is significantly faster when it doesn't flush at every call.
This is by a factor of 4 on Linux and 10 on Windows when sending typical per-row blocks of 60 byte.

put_copy_end unconditionally calls flush in libpq, so it is not changed here.

Also adjust conn.block to send all enqueued data to mimic the behavior of get_result in libpq.
With the change to put_copy_data, unsent data can happen, when largs blocks are sent.
In this case get_result should catch up on flush.
This is what the newly added spec verifies.

PQgetResult does flushing based on it's internal states that we don't have access to.
Since conn.block is performance critical in case of single_row_mode, we don't flush at every call to conn.block, but only when it's about to wait for IO.
    @larskanis
    larskanis committed Jun 14, 2022
    Configuration menu
    Copy the full SHA
    db506d1 View commit details
    Browse the repository at this point in the history