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

Migrate from lib/pq to jackc/pgx #616

Closed
BenjaminPelletier opened this issue Nov 13, 2021 · 3 comments
Closed

Migrate from lib/pq to jackc/pgx #616

BenjaminPelletier opened this issue Nov 13, 2021 · 3 comments
Labels
feature Issue would improve software P2 Normal priority

Comments

@BenjaminPelletier
Copy link
Member

The Postgres client we are using is in maintenance mode and suggests that pgx is more actively developed. We should migrate to the more actively-developed client.

See #467 for an old, un-merged PR that attempted to do this.

@pratibhagupta2109
Copy link
Contributor

There are few concerns reported by other developers regarding the migration of lib/pg tojackc/pgxas listed in below mentioned comment and issue:
golang-migrate/migrate#512 (comment)
lib/pq#1022

Please review if these are applicable to our migration too.

@BenjaminPelletier
Copy link
Member Author

Those are both great links to know about. On a cursory read, my guess is that the problems may have primarily stemmed from user error, but I'm definitely not sure. To mitigate our risk, it would be great to do as little work as possible to get pgx working on enough of the DSS to allow us to benchmark its performance (and verify it doesn't have lots of errors). I think a good performance benchmark will be one or more of our "heavy concurrent" tests -- we can (perhaps temporarily) add a couple lines to those tests to note the clock before the test starts and after it completes, then run the test ~5 times with pq then ~5 times with pgx and compare the performance. If pgx performs at least, say, 90% as well as pq and doesn't have errors, then switching to a maintained (and recommended) project is probably a good strategy. If we see errors or substantial performance problems, then we'll know to stick with pq.

@BenjaminPelletier
Copy link
Member Author

Resolved by #679

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Issue would improve software P2 Normal priority
Projects
None yet
Development

No branches or pull requests

2 participants