brianc
Implement Batch query package
whoah this is really awesome! I'm excited to help get this over the finishline & release it.
@charmander any thoughts on this? I think it looks p great!
If it’s going to be a separate package instead of an API change to pg’s default query type – why in this repo?
I had to make changes in the types/pg to get the build running again Here is the PR waiting for the maintainers (@brianc, @charmander ) https://github.com/DefinitelyTyped/DefinitelyTyped/pull/65348
I think this important question remains unanswered
If it’s going to be a separate package instead of an API change to pg’s default query type – why in this repo
in other words : are maintainers of this repo willing to take responsability for this new package ?
In other words : are maintainers of this repo willing to take responsability for this new package ?
@abenhamdine I have followed what @brianc advised me here. But ofcourse it will be good to have confirmation again
Is this still alive / any help needed to get this done? I would like to use this myself.
Given this is a fully separate package, I can just publish and use this on its own without having to maintain my own fork of node postgres right? I might do that.
Edit: tried it out on some micro benchmarks. For updates I saw no real advantage compared to building a single big parametrized query. And for more than 50 rows, the big parametrized query is significantly faster. For inserts I'm seeing worse results compared to a big parametrized query.
@hillac could you show the code where it didnt work for you ? Im curious since the bench.ts file showed triple the qps I had seen otherwise.
https://github.com/hillac/pg-batch-bench Pulled the benchmark out into it's own repo. Example output in the readme.
I should change it to do the inserts and updates multiple times to get some percentiles and means, but you can pretty clearly see a trend that just building a large parameterized query is faster.
The batch is much nicer to use though. And might be a bit faster for single inserts, but that could just be a jit warmup thing. Once again, needs better statistics.
(Edit: Added some more iterations of inserting 1, 2 and 3 rows and batch is definitely slower, so likely just a jit warmup issue.)
I think your benchmark compared multiple round trip single inserts/ updates, which is slower. This benchmark does a single query with all the rows in it.