pgsql: Recent changes in memory management in tuplesort.c had a problem:

From: tgl(at)postgresql(dot)org (Tom Lane)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Recent changes in memory management in tuplesort.c had a problem:
Date: 2006-03-10 23:19:00
Message-ID: 20060310231900.B94B29DCC6F@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Log Message:
-----------
Recent changes in memory management in tuplesort.c had a problem: the
case where we run low on array slots before we run low on memory is much
more probable than I had thought, and so it's important to treat each
tape fairly in that case. To fix this, track per-tape slot allocations
just like we track per-tape space allocation. Also, in the FINALMERGE
code path avoid scanning all the input tapes when we really only need to
read from one. This should fix poor behavior with very large work_mem
as exhibited by Stefan Kaltenbrunner.
I didn't do anything about putting an upper bound on the number of tapes,
but maybe we should still consider that.

Modified Files:
--------------
pgsql/src/backend/utils/sort:
tuplesort.c (r1.64 -> r1.65)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/sort/tuplesort.c.diff?r1=1.64&r2=1.65)

Browse pgsql-committers by date

  From Date Subject
Next Message Neil Conway 2006-03-11 01:19:22 pgsql: Remove a few places that attempted to define INT_MAX, SCHAR_MAX,
Previous Message James William Pye 2006-03-10 21:42:22 python - pq: Raise the exception, not return.