Brett Okken

Specific to arrays there is a PR (https://github.com/pgjdbc/pgjdbc/pull/1194) which proposes some significant changes to how arrays are parsed. I do have some concerns with making changes towards a goal (such...

Would it make sense to do these changes in a branch and let the changes aggregate there until there is workable/testable support for graal? I am fairly ambivalent on this....

I see 2 distinct, but related problems. 1. Consensus on set of changes 2. Getting agreed upon changes merged Putting the graal related changes in aggregate in a branch helps...

@vlsi, any consideration for including this in 42.2.3 also? It is along the lines of the other performance improvements (reduced memory consumption and execution time) in the Parser class.

> Is there a compelling reason to add it now? Simply that it is is line with other optimizations in parsing. Not super compelling. > Even though this looks like...

``` @Fork(value = 1, jvmArgsPrepend = "-Xmx128m") @Measurement(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS) @Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS) @State(Scope.Thread) @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Threads(value =...

Memory impacts are very small as long as the value (index into sql length of the bind variable) is < 128 (cached Integer values). Then it becomes ~16 bytes per...

> > It is not an actual List implementation. It only implements a very few methods and is really quite simple > > Well, the reality with pgjdbc development is...

It is a minor improvement. Per sql statement parsed, it is ~10ns per bind variable and ~16 bytes per bind variable at position > 128 in the "native" sql satement....

I would be a big fan of having regularly scheduled releases.