Re: introduce optimized linear search functions that return index of matching element

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, sawada(dot)mshk(at)gmail(dot)com
Subject: Re: introduce optimized linear search functions that return index of matching element
Date: 2022-10-12 05:57:16
Message-ID: CAFBsxsFiC0gmaoJ54uJHubnTojzoL3ZYdt3PR-jNYpzgrgb1og@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 17, 2022 at 12:29 PM Nathan Bossart <nathandbossart(at)gmail(dot)com>
wrote:
>
> On Fri, Sep 16, 2022 at 02:54:14PM +0700, John Naylor wrote:
> > v6 demonstrates why this should have been put off towards the end.
(more below)
>
> Since the SIMD code is fresh in my mind, I wanted to offer my review for
> 0001 in the "Improve dead tuple storage for lazy vacuum" thread [0].
> However, I agree with John that the SIMD part of that work should be left
> for the end

As I mentioned in the radix tree thread, I don't believe this level of
abstraction is appropriate for the intended use case. We'll want to
incorporate some of the low-level simd.h improvements later, so you should
get authorship credit for those. I've marked the entry "returned with
feedback".

--
John Naylor
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-10-12 06:03:54 Re: Expose Parallelism counters planned/execute in pg_stat_statements
Previous Message kuroda.hayato@fujitsu.com 2022-10-12 05:56:02 RE: test_decoding assertion failure for the loss of top-sub transaction relationship