Re: [PATCH] avoid double scanning in function byteain - Mailing list pgsql-hackers

From Stepan Neretin
Subject Re: [PATCH] avoid double scanning in function byteain
Date
Msg-id CA+Yyo5TA6FQkydvXc4fZGN4ExLsQSVOrJMF3ek0UsKnsGu0Ayw@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] avoid double scanning in function byteain  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] avoid double scanning in function byteain
List pgsql-hackers


On Sat, Jul 19, 2025 at 3:48 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
I wrote:
> I'm inclined to accept 0001, reject 0002, and move on.  This doesn't
> seem like an area that's worth a huge amount of discussion.

Done that way.  I made a couple more cosmetic changes and added
test cases for the double-backslash code path (which hadn't been
covered in byteaout either, I see now).

BTW, in my hands the microbenchmark that Stepan suggested shows the
committed version to be about 40% faster than before for long input.
So apparently the StringInfo-ification suggested in 0002 gave back
just about all the performance gain from 0001.

                        regards, tom lane

Hi Tom,

Thanks a lot for reviewing and committing the change — much appreciated!

I agree with your rationale regarding patch 0001 vs 0002. It makes sense to avoid the overhead of StringInfo in this context, especially given the measurable performance benefit from the simpler approach.

One small thing: it seems the commit or diff with the final adjustments and test additions wasn't attached or linked in the thread. Could you please point me to the commit hash or reference? I’d love to take a look at the final version.

Best regards,
Stepan Neretin 

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: track generic and custom plans in pg_stat_statements
Next
From: Michael Paquier
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?