Horton
Menu

Re: [PATCH] Fix hashed ScalarArrayOp semantics for NULL LHS with non-strict comparators

David Rowley <dgrowleyml@gmail.com>

View thread
From: David Rowley <dgrowleyml@gmail.com>
To: Chengpeng Yan <chengpeng_yan@outlook.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, cca5507 <cca5507@qq.com>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2026-04-23T05:32:43Z
Lists: pgsql-hackers 
Thanks for looking.

On Thu, 23 Apr 2026 at 16:31, Chengpeng Yan <chengpeng_yan@outlook.com> wrote:
> One possible improvement, though not
> a blocker, would be to defer the lhs-NULL handling until we actually
> encounter the first NULL on the lhs. That could avoid a bit of extra
> work in the common case where the lhs contains no NULLs.

I thought of it, but didn't do it as it meant having to keep a bit
more state to track if we've filled the cache yet, plus the extra
costs incurred to check if we've done it yet that would have to be
paid for every NULL lookup. We currently have to check if the hash
table has been set up already, so I felt more comfortable installing
the new code in with that.

David

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix incorrect logic for hashed IN / NOT IN with non-strict operators