Re: Make tsqueryout() use a StringInfo

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

Hi,

On Sun, 16 Aug 2026 at 23:34, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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.
>

Fair enough. I agree this probably isn't worth special-casing without a
realistic workload that demonstrates a problem.

It just seemed a decent bump hence called it out, the rest of the patch
looks good to me.

Regards,
Ayush

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mats Kindahl 2026-08-16 18:42:33 Re: Batching in executor
Previous Message Tom Lane 2026-08-16 18:04:20 Re: Make tsqueryout() use a StringInfo