Re: Use of "long" in incremental sort code
| От | David Rowley |
|---|---|
| Тема | Re: Use of "long" in incremental sort code |
| Дата | |
| Msg-id | CAApHDvq8F=CY2Qqy6czn1+E9YaBPCLkhGMo7gSOep=NtaoGPFg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Use of "long" in incremental sort code (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Use of "long" in incremental sort code
|
| Список | pgsql-hackers |
On Tue, 30 Jun 2020 at 16:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: > There is a fairly widespread issue that memory-size-related GUCs and > suchlike variables are limited to represent sizes that fit in a "long". > Although Win64 is the *only* platform where that's an issue, maybe > it's worth doing something about. But we shouldn't just fix the sort > code, if we do do something. > > (IOW, I don't agree with doing a fix that doesn't also fix work_mem.) I raised it mostly because this new-to-PG13-code is making the problem worse. If we're not going to change the in-memory fields, then shouldn't we at least change the ones for disk space tracking? David
В списке pgsql-hackers по дате отправления: