Re: Memory allocation in spi_printtup() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Memory allocation in spi_printtup()
Date
Msg-id 20936.1439823361@sss.pgh.pa.us
Whole thread Raw
In response to Memory allocation in spi_printtup()  (Neil Conway <neil.conway@gmail.com>)
Responses Re: Memory allocation in spi_printtup()  (Neil Conway <neil.conway@gmail.com>)
List pgsql-hackers
Neil Conway <neil.conway@gmail.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Raising our compiler requirements for 9.6
Next
From: Andrew Dunstan
Date:
Subject: Re: what would tar file FDW look like?