Horton

Re: [PATCH] avoid double scanning in function byteain

Stepan Neretin <slpmcf@gmail.com>

View thread
From: Stepan Neretin <slpmcf@gmail.com>
To: Aleksander Alekseev <aleksander@timescale.com>
Cc: pgsql-hackers@lists.postgresql.org, Steven Niu <niushiji@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>
Date: 2025-05-09T14:39:02Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Speed up byteain by not parsing traditional-style input twice.

On Fri, May 9, 2025 at 7:43 PM Aleksander Alekseev <aleksander@timescale.com>
wrote:

> Hi Stepan,
>
> > Sorry for the noise — I'm resending the patch because I noticed a
> compiler warning related to mixed declarations and code, which I’ve now
> fixed.
> >
> > Apologies for the oversight in the previous submission.
>
> Thanks for the patch.
>
> As Kirill pointed out above, it would be nice if you could prove that
> your implementation is actually faster. I think something like a
> simple micro-benchmark will do.
>
> --
> Best regards,
> Aleksander Alekseev
>


Hi,

Thanks for the feedback.

I’ve done a simple micro-benchmark using PL/pgSQL with a large escaped
input string (\\123 repeated 100,000 times), converted to bytea in a loop:

DO $$
DECLARE
    start_time TIMESTAMP;
    end_time TIMESTAMP;
    i INTEGER;
    dummy BYTEA;
    input TEXT := repeat(E'\\123', 100000);
    elapsed_ms DOUBLE PRECISION;
BEGIN
    start_time := clock_timestamp();

    FOR i IN 1..1000 LOOP
        dummy := input::bytea;
    END LOOP;

    end_time := clock_timestamp();
    elapsed_ms := EXTRACT(EPOCH FROM end_time - start_time) * 1000;
    RAISE NOTICE 'Average time per call: % ms', elapsed_ms / 1000;
END
$$;

Here are the results from NOTICE output:

*Without patch:*

NOTICE:  Average time per call: 0.49176600000000004 ms
NOTICE:  Average time per call: 0.47658999999999996 ms

*With patch:*

NOTICE:  Average time per call: 0.468231 ms
NOTICE:  Average time per call: 0.463909 ms

The gain is small but consistent. Let me know if a more rigorous benchmark
would be useful.

Best regards,
Stepan Neretin