| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | James Coleman <jtc331(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Use of "long" in incremental sort code |
| Date: | 2020-06-30 04:24:00 |
| Message-ID: | CAApHDvq8F=CY2Qqy6czn1+E9YaBPCLkhGMo7gSOep=NtaoGPFg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 30 Jun 2020 at 16:20, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2020-06-30 04:34:22 | Re: truncating timestamps on arbitrary intervals |
| Previous Message | Ashutosh Bapat | 2020-06-30 04:22:44 | Re: POC: postgres_fdw insert batching |