Re: Avoid repeated scans of the output buffer in oidvectortypes()

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: Japin Li <japinli(at)hotmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid repeated scans of the output buffer in oidvectortypes()
Date: 2026-10-15 12:49:43
Message-ID: CAApHDvrCYTkX=_KAuNSzyQjoRAkOpxNonrsZzLzyHFHBrenX+w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 16 Oct 2026 at 01:16, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> I tried StringInfo first. A few minor reasons led me to choose the v1 approach:
>
> * v1 made fewer changes to the existing code.
> * v1 was slightly faster in my test. With debug and assertions disabled, v1 took about 20 ms and StringInfo about 24 ms, averaged over multiple runs.

I doubt that matters very much. I think your test case isn't that
realistic anyway, as it uses InvalidOid. I tried exercising it with:
SELECT length(oidvectortypes(repeat('1043 ', 100)::oidvector));

Which gives:

master: tps = 9427.119361
v1: tps = 9684.447542
v2: tps = 9681.868182
v2b: tps = 9707.819189

v2b just replaces the appendStringInfoString(&result, ", "); with
appendBinaryStringInfo(&result, ", ", 2);

> I agree that using the usual API outweigh these minor considerations. I've updated the patch to use StringInfo in v2.

v2 looks fine to me.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2026-10-15 13:06:00 RE: [PG19] Promotion hangs behind a backend blocked on a stuck client
Previous Message Nitin Jadhav 2026-10-15 12:47:54 Re: [PATCH] Fix recovery connection detail in EXEC_BACKEND builds