Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQXVP-0004bd-Oo for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Aug 2022 17:15:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oQXVO-0006Yw-EU for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Aug 2022 17:15:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQXVO-0006Yg-3a for pgsql-hackers@lists.postgresql.org; Tue, 23 Aug 2022 17:15:58 +0000 Received: from mail-pg1-x52d.google.com ([2607:f8b0:4864:20::52d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oQXVH-0002YU-3v for pgsql-hackers@postgresql.org; Tue, 23 Aug 2022 17:15:57 +0000 Received: by mail-pg1-x52d.google.com with SMTP id d71so12805048pgc.13 for ; Tue, 23 Aug 2022 10:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc; bh=X0kGj0q8JHIJ8zqVf3sYTVn05006UQ7IVUvoXYFfjc4=; b=eGPhIKyZDwypWVFZsyQldc8o1xZ8SR0wHHGxDTRqpwwHkXeeCc2HEFtgy2kGUJcEiO 449jP+VuVd3dow54q00S/pRorERIRbvc4fiz8adYDdKN3MCrSJi7CPq0jZM0K4nF9MZ0 vWDqfKtMVqADSIFNh0mrTR5MqPTe6DILp3OolvBqVxvmg/3oM3MNgDolb59R8/sCjPE8 WGtffhwpydO7ROSNVRGu4+JQNIladXJrlDZ4CScgsKi7Yl804JflEaT0nbiEi+1EoffR AtongyiSboHRBZaKPBqPl+4f1cHT6dr9JfXKrXoasEgf08rvnJhP90MEmQe6yFZ9aGH1 IOvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=X0kGj0q8JHIJ8zqVf3sYTVn05006UQ7IVUvoXYFfjc4=; b=aUeX6/9zJaDEdNhcH8BPSy45Y6JKYY0SiQ2FuQlPUnoRsttUREpMvgGqzm1SX6fB8v rjZinfFW3foVjM4nIm2NPUqk0WY93Te43jT9bxpuFmH2MtAEk686dJ7lJF8wCtivSkp8 Lq4KypP74kvEeAej0bU3LIIVCkm+fozQO50f2P9e11Ko+uuGqIEXoYx8ApC5DochOUbK uu5boShTgbbligXZ6LiPhsu7xB4gX2a8DgTtNfzR7KMXA1yoWcW1XSZTE3vbq5xqFbUt yj5iOuyylYOt10/uArSub3FFLqToAd3GLoXVKsLMKsXz5qcJN38S131ZmIWjhgTTf3f1 KenQ== X-Gm-Message-State: ACgBeo09Syt5daAEzM7KjpoSUQOzsQ5Ff/JC7lavbMh1l3Vk8P7pgEG8 RLthRhLrIWkuRiU/okha/hQ= X-Google-Smtp-Source: AA6agR5Ndi1KU2ufKX7l7Ve/uFKyrsVUw/6TqzCSAZ5UaY0YLN7K4yElz6ibSP6vf+boLxlm5LeeQw== X-Received: by 2002:a63:6848:0:b0:42a:f726:5f2c with SMTP id d69-20020a636848000000b0042af7265f2cmr2165238pgc.518.1661274948857; Tue, 23 Aug 2022 10:15:48 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id h12-20020a170902f54c00b0016ee328fd61sm1312924plf.198.2022.08.23.10.15.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Aug 2022 10:15:48 -0700 (PDT) Date: Tue, 23 Aug 2022 10:15:46 -0700 From: Nathan Bossart To: John Naylor Cc: Andres Freund , Tom Lane , Jelte Fennema , "pgsql-hackers@postgresql.org" , Merlin Moncure , Andrew Dunstan , Stephen Frost Subject: Re: [PATCH] Optimize json_lex_string by batching character copying Message-ID: <20220823171546.GA1207981@nathanxps13> References: <20220815212304.GA251709@nathanxps13> <20220819204215.GA397534@nathanxps13> <20220821054733.GA780295@nathanxps13> <20220822212229.GA1129243@nathanxps13> <20220823033236.GA1204962@nathanxps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Aug 23, 2022 at 01:03:03PM +0700, John Naylor wrote: > On Tue, Aug 23, 2022 at 10:32 AM Nathan Bossart >> Here's a new version of the patch with the 32-bit changes and calls to >> lfind() removed. > > LGTM overall. My plan is to split out the json piece, adding tests for > that, and commit the infrastructure for it fairly soon. Possible > bikeshedding: Functions like vector8_eq() might be misunderstood as > comparing two vectors, but here we are comparing each lane with a > scalar. I wonder if vector8_eq_scalar() et al might be more clear. Good point. I had used vector32_veq() to denote vector comparison, which would extend to something like vector8_seq(). But that doesn't seem descriptive enough. It might be worth considering vector8_contains() or vector8_has() as well. I don't really have an opinion, but if I had to pick something, I guess I'd choose vector8_contains(). -- Nathan Bossart Amazon Web Services: https://aws.amazon.com