On Thu, Jun 25, 2026 at 12:30 PM Bharath Rupireddy <[email protected]> wrote: > > Hi, > > On Thu, Jun 25, 2026 at 11:28 AM Masahiko Sawada <[email protected]> > wrote: > > > > Since commit ec8719ccbfcd made hex_decode_safe() SIMD-aware, decoding > > a run of hex digits is now fast. The attached patch reuses > > hex_decode_safe() in the UUID input function to speed up parsing. > > > > We accept several textual forms of a UUID[1]. The fast path handles > > the common ones: 32 hex digits, the canonical 8x-4x-4x-4x-12x form > > (where "nx" means n hex digits), and either of those wrapped in > > braces. Otherwise, it falls back to the ordinary scalar UUID parse. > > > > I've benchmarked the parse speed using the following query: > > > > CREATE TEMP TABLE u AS SELECT gen_random_uuid()::text AS t FROM > > generate_series(1, 1000000); > > EXPLAIN (ANALYZE, TIMING OFF) SELECT t::uuid FROM u; > > > > I compared the execution time of the second query, which measures > > uuid_in() alone, with/without SIMD optimization. Here are results (the > > median of 5 runs): > > > > HEAD: 208.879 ms > > Patched: 40.983 ms > > Nice! > > > The improvements look promising to me. But in a realistic pipeline the > > parse is a small fraction of the work, so end-to-end gains could be > > much smaller. > > > > Feedback is very welcome. > > I had a quick look at the patch. It mostly looks good to me. I like > the idea of falling back to the scalar path when an error occurs - a > neat user experience. > > I think it's not worth adding a test case for this because I believe > this code gets covered anyway from existing tests. > > A few comments: > > 1/ > + * pass the local esctx instead of escontext to hex_decode_safe() to > > Instead of using variable names in the comments, let's say something > like: we pass a separate error context to detect errors in the SIMD > path and fall back to the normal path instead of raising ERRORs, for a > better user experience.
Agreed. > > 2/ > + if (esctx.error_occurred) > + string_to_uuid_scalar(source, uuid, escontext); > > An error on supported platforms seems rare, but when one occurs, I > think it's worth emitting a WARNING or LOG message. This way the query > succeeds, but later in the server logs, if noticed, it could provide > useful reasoning or uncover issues in the SIMD code. Hmm, I'm concerned that emitting a WARNING or LOG message whenever parsing uncommon UUID forms might be annoying rather useful. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
