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 1oP8p0-0003J7-Qc for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Aug 2022 20:42:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oP8ox-0004nT-JG for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Aug 2022 20:42:23 +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 1oP8ox-0004nJ-8C for pgsql-hackers@lists.postgresql.org; Fri, 19 Aug 2022 20:42:23 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oP8ou-0008SH-BB for pgsql-hackers@postgresql.org; Fri, 19 Aug 2022 20:42:22 +0000 Received: by mail-pj1-x102b.google.com with SMTP id f21so5677921pjt.2 for ; Fri, 19 Aug 2022 13:42:19 -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=dRC1/i5c8O5bKBMvOJQW4+PrSnihwVS6n7RCaHZK+Pk=; b=DipEEm6MltRFriJAUZdf+JxwstA7a8nRIL+Py4og8SPeUbgH+BlfMMFppEm30Kq7H+ NHsxi3zy7X7WBkpcrxew5aUjNBwkaZd5wcimrafeHFLHMmV8gxxeBtLgEMR1CryERf9A 7oeVMrlpAv4cYoyN0Jjlm2nb0Y9qNVO2+syQg2+H+bRl5WEZMc/3yXy4kvvKDDmaA1Di 58AQpyGaKOBiTINMcMd1zHo56TGPnW7+VFzWOO7da9udkS1eFqjA24m5RUzOEyq3s2b8 4hQNgu4Fclzv2vTXwoeD7amqOG9KzJcJXkpgcecbxJ0INmcaVkZLjhVsKKczktfzM7fs HIkw== 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=dRC1/i5c8O5bKBMvOJQW4+PrSnihwVS6n7RCaHZK+Pk=; b=JDUFojULFXl+QTPbex11yihWGAmzEbYbHEWoELdy5VSjpo2wKE01RBjPmcQACePg8C Vul49sBu+BYH9cmT8huAVRyflzF4+eXrk1LaONhNjuw2b/f8JKiWpBxuI3PesczqgN3A 0wksKE3fQLOMKPULu4iGrpPN1vQRjWRM4JqdAo/P5f2IqV17henPCtybQ6+hRZXopVgq 7gGwSrWjYl/r73txUxBEtoCwxesoCYshNAb4NkNzshK3xteUuqDpgYHBndkNQUuLy838 LQgH7rdNNz4reLkUyCs1ynYw67JU6wOloO7XW16quTDEjtJqxXN063joGIctC03DtjF0 u2Hg== X-Gm-Message-State: ACgBeo020DZTDZjMKgszJPdfuHlwrHP3qCeLLIeFPor0ILcGDPqQ8xrK RWYpFBkTakQw3VBI7Iqw+fU= X-Google-Smtp-Source: AA6agR5MQEtzBXippIDsu1R95wCRD8kgzK7M8TE4drIfh7/FtvrALtfQyI8SMz0jrsgR9ulq/y15+A== X-Received: by 2002:a17:90b:3d8d:b0:1fa:ced8:dfc9 with SMTP id pq13-20020a17090b3d8d00b001faced8dfc9mr9090120pjb.171.1660941738086; Fri, 19 Aug 2022 13:42:18 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id g5-20020a170902d1c500b0016eea511f2dsm3523225plb.242.2022.08.19.13.42.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Aug 2022 13:42:17 -0700 (PDT) Date: Fri, 19 Aug 2022 13:42:15 -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: <20220819204215.GA397534@nathanxps13> References: <20220706051801.gfbzjxgflbsglyt6@awork3.anarazel.de> <20220711154150.hwzw7qw2k6iahofy@awork3.anarazel.de> <1119852.1657554806@sss.pgh.pa.us> <20220711160728.tljbnowfgxefdbli@awork3.anarazel.de> <20220815212304.GA251709@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 Fri, Aug 19, 2022 at 03:11:36PM +0700, John Naylor wrote: > This is done. Also: > - a complete overhaul of the pg_lfind8* tests > - using a typedef for the vector type > - some refactoring, name changes and other cleanups (a few of these > could also be applied to the 32-byte element path, but that is left > for future work) > > TODO: json-specific tests of the new path This looks pretty good to me. Should we rename vector_broadcast() and vector_has_zero() to indicate that they are working with bytes (e.g., vector_broadcast_byte())? We might be able to use vector_broadcast_int() in the 32-bit functions, and your other vector functions already have a _byte suffix. In general, the approach you've taken seems like a decent readability improvement. I'd be happy to try my hand at adjusting the 32-bit path and adding ARM versions of all this stuff. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com