Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, James Coleman <jtc331@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-04-23T22:35:44Z
Lists: pgsql-hackers
Hi, On 2020-04-24 10:09:36 +1200, David Rowley wrote: > If single comparison for a binary search costs about the same as an > equality check, then wouldn't the crossover point be much lower than > 64? The costs aren't quite as simple as that though. Binary search usually has issues with cache misses: In contrast to linear accesses each step will be a cache miss, as the address is not predictable; and even if the CPU couldn't predict accesses in the linear search case, often multiple entries fit on a single cache line. Additionally out-of-order execution is usually a lot more effective for linear searches (e.g. the next elements can be compared before the current one is finished if that's what the branch predictor says is likely). Greetings, Andres Freund
Commits
-
Use a hash table to speed up NOT IN(values)
- 29f45e299e7f 15.0 landed
-
Speedup ScalarArrayOpExpr evaluation
- 50e17ad281b8 14.0 landed