Thanks for looking at this On Fri, Apr 19, 2019 at 09:46:18PM -0000, PyGreSQL issue tracker wrote: > But I think the huge performance difference in your example is only an > artifact of the special kind of query you were using, with very simple > values (just integer zeroes) and many columns.
FWIW this is our workload at telsasoft. We have very wide tables (historically some up to the postgres limit of 1600 columns), nearly all of which are small/big/int/float/double. > This is because strings need to be escaped when inserted inline, which > turns the tide against inline=True. Good point :) > I also had a look at the code, checked with a profiler and made some > optimizations in r970, r971 and r972, but did not really find much more we > can do here, at least no low-hanging fruits. The optimizations in your > patch will not work in the general case, when you have mixed parameters > containing Literal values. Also, caching the types of the values works > only if you have very few different values (like in your case only a > zero), but for most real-world examples with different strings or floats > this will not work. Do you mean "..works only if you have very few different TYPES OF values" ? > So I think the best we can do is document the issue as you suggested, and > refer to `query` and `query_prepared` for performance-critial queries and > batch runs which I have done in r973. Thank you. I think this is sufficient. Justin _______________________________________________ PyGreSQL mailing list PyGreSQL@Vex.Net https://mail.vex.net/mailman/listinfo/pygresql
