Message-ID: <gh-pgjdbc-pgjdbc-3657-rc2180362089@github.com>
From: "vlsi (@vlsi)" <noreply+vlsi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Wed, 02 Jul 2025 15:27:21 +0000
Subject: Re: [pgjdbc/pgjdbc] PR #3657: perf: cache composite and simple subqueries
In-Reply-To: <gh-pgjdbc-pgjdbc-3657@github.com>
References: <gh-pgjdbc-pgjdbc-3657@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: vlsi
X-GitHub-Comment-Id: 2180362089
X-GitHub-Comment-Type: review_comment
X-GitHub-Commit: a757e8efffb0fdeeb39e031167bb14c539e98542
X-GitHub-Issue: 3657
X-GitHub-Line: 76
X-GitHub-Path: benchmarks/src/jmh/java/org/postgresql/benchmark/statement/SelectBatch.java
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: review_comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/3657#discussion_r2180362089
Content-Type: text/plain; charset=utf-8

(on benchmarks/src/jmh/java/org/postgresql/benchmark/statement/SelectBatch.java:76)

Frankly speaking, I am afraid it is a suboptimal way of executing the queries.

The suggested SQL would have:
* 1-query statement
* 2-query statement
* 3-query statement
* ...
* 1000-query statement

That would consume n^2 memory.

The typical approach for these type of workloads is to use 2^N splits:

* 1-query statement
* 2-query statement
* 4-query statement
* 8-query statement
* 16-query statement
* 32-query statement
* 64-query statement
* 128-query statement
* 256-query statement
* 512-query statement
* 1024-query statement

Then you would have 11 queries that would be enough to cover any possible number of queries in a range of 1..2047.

For instance executing 356 would require 256+64+32+4=356.

WDYT?