Re: Memory allocation in spi_printtup()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neil(dot)conway(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory allocation in spi_printtup()
Date: 2015-08-17 14:56:01
Message-ID: 20936.1439823361@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Neil Conway <neil(dot)conway(at)gmail(dot)com> writes:

Hi Neil! Long time no see.

> spi_printtup() has the following code (spi.c:1798):
> if (tuptable->free == 0)
> {
> tuptable->free = 256;
> tuptable->alloced += tuptable->free;
> tuptable->vals = (HeapTuple *) repalloc(tuptable->vals,
> tuptable->alloced * sizeof(HeapTuple));
> }

> i.e., it grows the size of the tuptable by a fixed amount when it runs
> out of space. That seems odd; doubling the size of the table would be
> more standard. Does anyone know if there is a rationale for this
> behavior?

Seems like it must be just legacy code. We're only allocating pointers
here; the actual tuples will likely be significantly larger. So there's
not a lot of reason not to use the normal doubling rule.

> Attached is a one-liner to double the size of the table when space is
> exhausted.

I think this could use a comment, but otherwise seems OK.

Should we back-patch this change? Seems like it's arguably a
performance bug.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2015-08-17 15:03:27 Re: what would tar file FDW look like?
Previous Message Andres Freund 2015-08-17 14:53:16 Re: Raising our compiler requirements for 9.6