On Wed, Jul 16, 2025 at 9:17 AM Mircea Cadariu wrote:
> Thanks for the elaboration and updated patch! Indeed, I see it's set in
> the ScanKeyEntryInitialize to either BTGreaterStrategyNumber or
> BTLessStrategyNumber, then few lines lower there's the if with the break.
>
> I'm convinced.
Pushed.
On 16/07/2025 07:27, Peter Geoghegan wrote:
[...] Rather, we rely on the generic logic that
builds our startKeys[] entries. It will inevitably "break" before ever
moving on to the next index attribute/next so->keyData[] key because
strat_total will inevitably become
BTGreaterStrategyNumber/BTLes
On Tue, Jul 15, 2025 at 4:50 PM Mircea Cadariu wrote:
> As an experiment, I added an elog(WARNING,...) just above the main changed
> line in the patch, and then ran the tests (make installcheck). This resulted
> in lines logged next to some of the SELECT statements in the following files
> in s
Hi,
On 07/07/2025 01:22, Peter Geoghegan wrote:
However, there's no reason why "ScanKeyData
notnullkeys[INDEX_MAX_KEYS]" needs to be an array at all. In practice,
_bt_first will only need a single temp notnullkeys ScanKeyData, since
there can never be more than a single deduced NOT NULL constrai
nbtree's _bt_first function uses arrays on the stack to store the scan
keys that will be used for initial positioning purposes. We could use
dynamic allocation here instead, but experience has shown that that
would cause performance issues -- particularly during nestloop joins
with an inner index s
