On 2016-03-17 20:11:00 +0000, Robert Haas wrote:
> Improve memory management for external sorts.
>
> Introduce a new memory context which stores tuple data, and reset it
> at the end of each merge pass; this helps avoid memory fragmentation
> and, consequently, overallocation. Also, for the final merge patch,
> eliminate memory context chunk header overhead entirely by allocating
> all of the memory used for buffering tuples during the merge in a
> single chunk. Since this modestly increases the number of tuples we
> can store, grow the memtuples array a bit so that we're less likely to
> run short of slots there.
>
> Peter Geoghegan. Review and testing of patches in this series by
> Jeff Janes, Greg Stark, Mithun Cy, and me.
Cross compiling for windows results in:
/home/andres/src/postgresql/src/backend/utils/sort/tuplesort.c: In function
‘beginmerge’:
/home/andres/src/postgresql/src/backend/utils/sort/tuplesort.c:2695:34:
warning: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has
type ‘int64 {aka long long int}’ [-Wformat=]
elog(LOG, "tape %d initially used %ld KB of %ld KB batch "
^
/home/andres/src/postgresql/src/backend/utils/sort/tuplesort.c:2695:34:
warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has
type ‘int64 {aka long long int}’ [-Wformat=]
config.status: creating src/interfaces/ecpg/include/ecpg_config.h
/home/andres/src/postgresql/src/backend/utils/sort/tuplesort.c: In
function ‘beginmerge’:
/home/andres/src/postgresql/src/backend/utils/sort/tuplesort.c:2695:34:
warning: format ‘%ld’ expects argument of type ‘long int’, but argument
4 has type ‘int64 {aka long long int}’ [-Wformat=]
elog(LOG, "tape %d initially used %ld KB of %ld KB batch "
Which seems like a valid complain on a LLP64 platform (i.e. where long
is 32bit) like windows.
Andres
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
