From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: David Rowley <dgrowleyml@gmail.com>,
        "ldh@laurent-hasson.com" <ldh@laurent-hasson.com>,
        Justin Pryzby <pryzby@telsasoft.com>,
        "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Big performance slowdown from 11.2 to 13.3
In-reply-to: 
 <CAH2-WznibcXu2Uxn3zaXqZCEZyOx3ehMvjy5-_8wJNvYtR3eVw@mail.gmail.com>
References: 
 <MN2PR15MB25601E80A9B6D1BA6F592B1985E39@MN2PR15MB2560.namprd15.prod.outlook.com>
 <20210721191528.GC19620@telsasoft.com>
 <MN2PR15MB256016E33F00DE60B96F02D385E39@MN2PR15MB2560.namprd15.prod.outlook.com>
 <CAH2-Wzm3rSAWHyENb3T0X8M_qdYjF1t7rntkMJ2kDiuhVOHx3g@mail.gmail.com>
 <MN2PR15MB2560C1A890DC07F9359FB56285E39@MN2PR15MB2560.namprd15.prod.outlook.com>
 <732758.1626911007@sss.pgh.pa.us>
 <MN2PR15MB2560778595BB7AF6E691B26785E39@MN2PR15MB2560.namprd15.prod.outlook.com>
 <MN2PR15MB2560D429866BD65A70574A6C85E49@MN2PR15MB2560.namprd15.prod.outlook.com>
 <CAApHDvqoF7y7SQjGT=940njnAd_CUcUG6oRYChcP_+eJyuNiug@mail.gmail.com>
 <MN2PR15MB25603D3CE06C8F9C312EA58985E49@MN2PR15MB2560.namprd15.prod.outlook.com>
 <MN2PR15MB2560E4574A6E2B5AED2C03CB85E49@MN2PR15MB2560.namprd15.prod.outlook.com>
 <784576.1626968702@sss.pgh.pa.us> <785218.1626969409@sss.pgh.pa.us>
 <CAApHDvo+Gb80BVPKYCwHbLa7a7ZXp9ziq9URrpQaKdvXsd46bg@mail.gmail.com>
 <786600.1626970898@sss.pgh.pa.us> <787780.1626972122@sss.pgh.p!
 a.us> <CAH2-WzkWU_YdyKWSV2HeNyJk=ou6ywPH4S7Gd3XoJqZFbxF_ZA@mail.gmail.com>
 <CAH2-Wzm9RuBzbq-h15TXTk7RQ_A8JfMk4kdGn_pQFuMsSPBJ+A@mail.gmail.com>
 <789413.1626973893@sss.pgh.pa.us>
 <CAH2-WznibcXu2Uxn3zaXqZCEZyOx3ehMvjy5-_8wJNvYtR3eVw@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Thu, 22 Jul 2021 10:27:43 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <790789.1626975347.1@sss.pgh.pa.us>
Date: Thu, 22 Jul 2021 13:35:47 -0400
Message-ID: <790790.1626975347@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/790790.1626975347%40sss.pgh.pa.us>
Precedence: bulk

Peter Geoghegan <pg@bowt.ie> writes:
> On Thu, Jul 22, 2021 at 10:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What I'm wondering about is whether it's worth putting in a solution
>> for this issue in isolation, or whether we ought to embark on the
>> long-ignored project of getting rid of use of "long" for any
>> memory-size-related computations.  There would be no chance of
>> back-patching something like the latter into v13, though.

> By requiring int64 be used instead of long, we don't actually increase
> risk for non-Windows platforms to any significant degree. I'm pretty
> sure that "long" means int64 on non-Windows 64-bit platforms anyway.

Well, what we really ought to be using is size_t (a/k/a Size), at least
for memory-space-related calculations.  I don't have an opinion right
now about what logtape.c ought to use.  I do agree that avoiding "long"
altogether would be a good ultimate goal.

In the short term though, the question is whether we want to regard this
hashagg issue as something we need a fix for in v13/v14.  The fact that
it's Windows-only makes it slightly less pressing in my mind, but it's
still a regression that some people are going to hit.

			regards, tom lane