Re: Bug in 9.6 tuplesort batch memory growth logic
От | Tom Lane |
---|---|
Тема | Re: Bug in 9.6 tuplesort batch memory growth logic |
Дата | |
Msg-id | 17301.1473167875@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Bug in 9.6 tuplesort batch memory growth logic (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Bug in 9.6 tuplesort batch memory growth logic
|
Список | pgsql-hackers |
Peter Geoghegan <pg@heroku.com> writes: > While working on my parallel CREATE INDEX patch, I came across a > problem. I took a quick look at this. I do not follow the logic in this new bit: + if (availMemLessRefund <= + (int64) state->activeTapes * ALLOCSET_DEFAULT_INITSIZE) + return; It doesn't seem to me that this limit has anything to do with anything, and the comment claiming only that it's "noncritical" isn't helping. If the point is to prevent the later LACKMEM check from failing, then certainly there is something critical somewhere. I'd rather see this explained as "we need at least X, but we choose to require at least Y to avoid repalloc thrashing". And maybe the code should use Max(X,Y) rather than blindly assuming that ALLOCSET_DEFAULT_INITSIZE exceeds whatever the true minimum is. regards, tom lane
В списке pgsql-hackers по дате отправления: