You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I did some experiments with sending flush more regularly & I saw query throughput on a very, very basic benchmark improve by about 10%. I'm wondering if this has more impact or less impact on situations with more latency as my benchmark was running locally. I'm particularly trying to shake out what's impacting things in #1993 and #1952
I also removed some sort of micro-optimization I made a long time ago that isn't helping anymore. I saw small speed increases, but I think it might help the ClienRead delays in certain cases. I was buffering up a bunch of messages in the process (parse, bind, execute) before sending any of them. Now I'm just writing them all to the wire when the come in, and following each w/ a sync to help the backend send it's responses as quickly as possible as well.
Hey @brianc, we're doing some checking up on how node-pg sends anonymous prepared statements and perf compared to libpq in binary_parameters mode. From my read of the code, node-pg actually handles this well because it doesn't do parse --- wait --- bind/describe/execute/flush, it just sends them all in one go, as libpq does in this mode. Please correct me if I am mis-reading. The main point of interest is compatibility with transaction pooling adapters such as pgbouncer which won't be able to keep state across multiple round-trips.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
brianc
changed the title
I did some experiments with sending flush more regularly & I saw query throughput on a very, very basic benchmark improve by about 10%. I'm wondering if this has more impact or less impact on situations with more latency as my benchmark was running locally. I'm particularly trying to shake out what's impacting things in #1993 and #1952
I also removed some sort of micro-optimization I made a long time ago that isn't helping anymore. I saw small speed increases, but I think it might help the ClienRead delays in certain cases. I was buffering up a bunch of messages in the process (parse, bind, execute) before sending any of them. Now I'm just writing them all to the wire when the come in, and following each w/ a sync to help the backend send it's responses as quickly as possible as well.