Re: Patch: Add parse_type Function - Mailing list pgsql-hackers

On 2024-02-18 20:00 +0100, Pavel Stehule wrote:
> The overhead of parse_type_and_format can be related to higher planning
> time. PL/pgSQL can assign composite without usage FROM clause.

Thanks, didn't know that this makes a difference.  In that case both
variants are on par.

    BEGIN;
    
    CREATE FUNCTION format_with_parse_type(text)
    RETURNS text
    LANGUAGE plpgsql
    STABLE STRICT
    AS $$
    DECLARE
        p record := parse_type($1);
    BEGIN
        RETURN format_type(p.typid, p.typmod);
    END
    $$;
    
    CREATE FUNCTION format_with_to_regtypmod(text)
    RETURNS text
    LANGUAGE plpgsql
    STABLE STRICT
    AS $$
    BEGIN
        RETURN format_type(to_regtype($1), to_regtypmod($1));
    END
    $$;
    
    COMMIT;

Results:

    SELECT format_with_parse_type('interval second(0)');

    pgbench (17devel)
    transaction type: format_with_parse_type.sql
    scaling factor: 1
    query mode: simple
    number of clients: 1
    number of threads: 1
    maximum number of tries: 1
    duration: 10 s
    number of transactions actually processed: 253530
    number of failed transactions: 0 (0.000%)
    latency average = 0.039 ms
    initial connection time = 1.846 ms
    tps = 25357.551681 (without initial connection time)

    SELECT format_with_to_regtypmod('interval second(0)');

    pgbench (17devel)
    transaction type: format_with_to_regtypmod.sql
    scaling factor: 1
    query mode: simple
    number of clients: 1
    number of threads: 1
    maximum number of tries: 1
    duration: 10 s
    number of transactions actually processed: 257942
    number of failed transactions: 0 (0.000%)
    latency average = 0.039 ms
    initial connection time = 1.544 ms
    tps = 25798.015526 (without initial connection time)

-- 
Erik