The official C postrgresql client used everywhere does not support said feature except with a patch from 2016. Only postrgresql can support such a feature but you need support on the postrgresql client too. The ability to do DB queries asynchronously and with batching is the differentiating factor. The thing is: on many of those benchmarcks, the bottleneck obviously is the DB. The answer is a deceptive one, they didn't achieve revolutionary optimizations. I had investigated what explained the huge gap between the few fastest frameworks vs the rest. But we feel the ranking seen in a continuous run such as this should be taken with a grain of salt until that next official round is available. Given the performance seen here, it is very likely that Lithium will be well ranked in the next official round. We execute runs like this continuously to allow maintainers of test implementations to observe the results of their contributions. Based on this link's attention, we'll make a more prominent warning for renderings of continuous runs so that they are more obvious to readers not familiar with the project.
You can tell from the title ("Test") and the UUID of the run visible in the gray box under the navigation. This link is to a rendering of data from a continuous run that hasn't received the type of sanity checking we do for an official TFB round. I don't want to take away from these results, but I do want to provide an important piece of context.
0 kommentar(er)
