| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jelte Fennema <Jelte(dot)Fennema(at)microsoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net> |
| Subject: | Re: [PATCH] Optimize json_lex_string by batching character copying |
| Date: | 2022-08-23 17:15:46 |
| Message-ID: | 20220823171546.GA1207981@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jonathan S. Katz | 2022-08-23 17:18:49 | Re: SQL/JSON features for v15 |
| Previous Message | Zhihong Yu | 2022-08-23 17:10:51 | handling multiple matching constraints in DetachPartitionFinalize() |