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? Attached is a one-liner to double the size of the table when space is exhausted. Constructing a simple test case in which a large result is materialized via SPI_execute() (e.g., by passing two large queries to crosstab() from contrib/tablefunc), this change reduces the time required to exceed the palloc size limit from ~300 seconds to ~93 seconds on my laptop. Of course, using SPI_execute() rather than cursors for queries with large result sets is not a great idea, but there is demonstrably code that does this (e.g., contrib/tablefunc -- I'll send a patch for that shortly). Neil
diff --git a/src/backend/executor/spi.c b/src/backend/executor/spi.c index d544ad9..2573b3f 100644 --- a/src/backend/executor/spi.c +++ b/src/backend/executor/spi.c @@ -1797,7 +1797,7 @@ spi_printtup(TupleTableSlot *slot, DestReceiver *self) if (tuptable->free == 0) { - tuptable->free = 256; + tuptable->free = tuptable->alloced; tuptable->alloced += tuptable->free; tuptable->vals = (HeapTuple *) repalloc(tuptable->vals, tuptable->alloced * sizeof(HeapTuple));
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers