Re: BUG #18080: to_tsvector fails for long text input

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: uwe(dot)binder(at)pass-consulting(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18080: to_tsvector fails for long text input
Date: 2023-09-22 19:31:10
Message-ID: 1146921.1695411070@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> BTW, the field order in ParsedWord is such that there's a fair
> amount of wasted pad space on 64-bit builds. I doubt we can
> get away with rearranging it in released branches; but maybe
> it's worth doing something about that in HEAD, to push out
> the point at which you hit the 1Gb limit.

I poked at that a little bit. We can reduce 64-bit sizeof(ParsedWord)
from 40 bytes to 24 bytes with the attached patch. The main thing
needed to make this pack tightly is to reduce the "alen" field from
uint32 to uint16. While it's not immediately obvious that that's
a good thing to do, a look at the one place where alen is increased
(uniqueWORD() in to_tsany.c) shows that it cannot get to more than
twice MAXNUMPOS:

if (res->pos.apos[0] < MAXNUMPOS - 1 && ...)
{
if (res->pos.apos[0] + 1 >= res->alen)
{
res->alen *= 2;
res->pos.apos = (uint16 *) repalloc(res->pos.apos, sizeof(uint16) * res->alen);
}

MAXNUMPOS is currently 256, and even if it's possible to increase
that it seems unlikely that we'd want to make it more than 32k.
So this limitation seems OK to me.

regards, tom lane

Attachment Content-Type Size
pack-ParsedWord-tightly.patch text/x-diff 859 bytes

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Christian Stork 2023-09-22 21:32:15 Re: BUG #18131: PL/pgSQL: regclass procedure parameter wrongly memoized(?)
Previous Message PG Bug reporting form 2023-09-22 19:22:34 BUG #18131: PL/pgSQL: regclass procedure parameter wrongly memoized(?)