Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
Date
Msg-id 6f62a5c3-6bb3-dead-9e58-d7f3bb3c8e6f@iki.fi
Whole thread Raw
In response to Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays  (James Coleman <jtc331@gmail.com>)
Responses Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays  (James Coleman <jtc331@gmail.com>)
List pgsql-hackers
On 01/05/2020 05:20, James Coleman wrote:
> On Tue, Apr 28, 2020 at 8:25 AM Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
> ...
>> Any particular reasons to pick dynahash over simplehash? ISTM we're
>> using simplehash elsewhere in the executor (grouping, tidbitmap, ...),
>> while there are not many places using dynahash for simple short-lived
>> hash tables. Of course, that alone is a weak reason to insist on using
>> simplehash here, but I suppose there were reasons for not using dynahash
>> and we'll end up facing the same issues here.
> 
> I've attached a patch series that includes switching to simplehash.
> Obviously we'd really just collapse all of these patches, but it's
> perhaps interesting to see the changes required to use each style
> (binary search, dynahash, simplehash).
> 
> As before, there are clearly comments and naming things to be
> addressed, but the implementation should be reasonably clean.

Looks good, aside from the cleanup work that you mentioned. There are a 
few more cases that I think you could easily handle with very little 
extra code:

You could also apply the optimization for non-Const expressions, as long 
as they're stable (i.e. !contain_volatile_functions(expr)).

Deconstructing the array Datum into a simple C array on first call would 
be a win even for very small arrays and for AND semantics, even if you 
don't use a hash table.

- Heikki



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Next
From: Masahiko Sawada
Date:
Subject: Re: display offset along with block number in vacuum errors