-
Notifications
You must be signed in to change notification settings - Fork 10
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
Revert to a single COPY operation per table instead of per chunk #308
Comments
<1> |
Still debugging some issues with restructuring the |
Perhaps rechunking the stream into larger chunks might help reduce the number of |
Hm, yeah that might be enough, good idea. We're seeing 3MiB chunks on the problematic instance now, so maybe we try rechunking to 32MiB and see if that helps. |
The per-chunk strategy appears to result in rather poor performance once data size increases. We'd like to revert to using a single
COPY
operation per-table to attempt to reclaim some performance. Some of the previous reliability concerns can be ameliorated via source buffering.In the case that we still run into reliability issues due to timeouts/long-running transactions a possible solution would be to define a maximum duration between writes to the
COPY
stream. If the threshold is reached, we commit the current operation and begin anew on the next chunk from upstream. This should avoid timeouts for slow sources while preserving performance where possible.The text was updated successfully, but these errors were encountered: