| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com>, 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 11:21:37 |
| Message-ID: | bc18a88a-ba6e-3a1f-a26f-434b2f7028b0@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-06-30 06:24, David Rowley wrote:
> 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.
Yeah, we recently got rid of a bunch of inappropriate use of long, so it
seems reasonable to make this new code follow that.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ants Aasma | 2020-06-30 11:30:03 | Re: track_planning causing performance regression |
| Previous Message | Asif Rehman | 2020-06-30 10:54:46 | Re: +(pg_lsn, int8) and -(pg_lsn, int8) operators |