On Sun, 2024-07-28 at 00:14 +0200, Andreas Karlsson wrote:
> But even without that extra optimization I think this patch is worth
> merging and the patch is small, simple and clean and easy to
> understand
> and a just a clear speed up. Feels like a no brainer. I think that it
> is
> ready for c
On 7/26/24 11:00 PM, Jeff Davis wrote:
Results (in ms):
"C" "libc_c" overhead
master:6350 7855 24%
v4-0001: 6091 6324 4%
I got more overhead in my quick benchmarking when I ran the same
benchmark. Also tried your idea with caching the last loo
On Thu, 2024-06-20 at 17:07 +0700, John Naylor wrote:
> On Sat, Jun 15, 2024 at 6:46 AM Jeff Davis wrote:
> > Attached is a patch to use simplehash.h instead, which speeds
> > things up
> > enough to make them fairly close (from around 15% slower to around
> > 8%).
>
> +#define SH_HASH_KEY(tb, ke
On Sat, Jun 15, 2024 at 6:46 AM Jeff Davis wrote:
> Attached is a patch to use simplehash.h instead, which speeds things up
> enough to make them fairly close (from around 15% slower to around 8%).
+#define SH_HASH_KEY(tb, key) hash_uint32((uint32) key)
For a static inline hash for speed reaso
On 15.06.24 01:46, Jeff Davis wrote:
* instead of a hardwired set of special collation IDs, have a single-
element "last collation ID" to check before doing the hash lookup?
I'd imagine that method could be very effective.
The blog post here (thank you depesz!):
https://www.depesz.com/2024/06/11/how-much-speed-youre-leaving-at-the-table-if-you-use-default-locale/
showed an interesting result where the builtin provider is not quite as
fast as "C" for queries like:
SELECT * FROM a WHERE t = '...';
The reason is
