Re: Make tsqueryout() use a StringInfo

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Make tsqueryout() use a StringInfo
Date: 2026-08-16 18:04:20
Message-ID: 571348.1786903460@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> writes:
> The patch looks good to me in general. One thing I wonder about is the
> increase in the initial allocation: the old code starts with 32 bytes,
> whereas initStringInfo() starts with 1024 bytes. ig this can add up when
> tsqueryout() is called by array_out(), since array_out() retains each
> element's output string while constructing the result?

I kinda doubt that a huge array of tsquery's is a realistic scenario.

> Would it make sense to use initStringInfoExt(&nrm.buf, 32) here, preserving
> the old initial size while retaining automatic growth?

I don't think so. Maybe there's an argument that 1024 is too large,
but I would say that 32 is much too small. Also there are plenty of
other places using the default buffer length without worrying about
this. It seems unlikely to me that quibbling over the value is really
going to be a productive use of brain cells.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ayush Tiwari 2026-08-16 18:14:57 Re: Make tsqueryout() use a StringInfo
Previous Message Tom Lane 2026-08-16 17:58:28 Re: pg_upgrade from pg19 source build to pg19-beta3 throws an error