Hi,
On 2021-07-26 11:38:41 +0900, Michael Paquier wrote:
> On Sun, Jul 25, 2021 at 12:28:04PM -0400, Tom Lane wrote:
> > Andres Freund writes:
> >> We really ought to just remove every single use of long.
> >
> > I have no objection to that as a long-term goal. But I'm not volunteering
> > to
On 2021-Jul-26, Tom Lane wrote:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> > We also have the (U)INT64CONST() macros, which are about about two
> > thirds as common as the U?LL? suffixes.
>
> Yeah. Ideally we'd forbid direct use of the suffixes and insist
> you go
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> We also have the (U)INT64CONST() macros, which are about about two
> thirds as common as the U?LL? suffixes.
Yeah. Ideally we'd forbid direct use of the suffixes and insist
you go through those macros, but I don't know of
Alvaro Herrera writes:
> On 2021-Jul-25, Ranier Vilela wrote:
>
>> > BTW, one aspect of this that I'm unsure how to tackle is the
>> > common usage of "L" constants; in particular, "work_mem * 1024L"
>> > is a really common idiom that we'll need to get rid of. Not sure
>> > that grep will be a
On 2021-Jul-25, Ranier Vilela wrote:
> > BTW, one aspect of this that I'm unsure how to tackle is the
> > common usage of "L" constants; in particular, "work_mem * 1024L"
> > is a really common idiom that we'll need to get rid of. Not sure
> > that grep will be a useful aid for finding those.
>
On Sun, Jul 25, 2021 at 12:28:04PM -0400, Tom Lane wrote:
> Andres Freund writes:
>> We really ought to just remove every single use of long.
>
> I have no objection to that as a long-term goal. But I'm not volunteering
> to do all the work, and in any case it wouldn't be a back-patchable fix.
Em dom., 25 de jul. de 2021 às 15:53, Tom Lane escreveu:
> Ranier Vilela writes:
> > I think int64 is in most cases the counterpart of *long* on Windows.
>
> I'm not particularly on board with s/long/int64/g as a universal
> solution.
Sure, not a universal solution, I mean a start point.
When
Ranier Vilela writes:
> I think int64 is in most cases the counterpart of *long* on Windows.
I'm not particularly on board with s/long/int64/g as a universal
solution. I think that most of these usages are concerned with
memory sizes and would be better off as "size_t". We might need
int64 in
Em dom., 25 de jul. de 2021 às 13:28, Tom Lane escreveu:
> Andres Freund writes:
> > On 2021-07-23 17:15:24 -0400, Tom Lane wrote:
> >> That's because they spill to disk where they did not before. The easy
> >> answer of "raise hash_mem_multiplier" doesn't help, because on Windows
> >> the
Andres Freund writes:
> On 2021-07-23 17:15:24 -0400, Tom Lane wrote:
>> That's because they spill to disk where they did not before. The easy
>> answer of "raise hash_mem_multiplier" doesn't help, because on Windows
>> the product of work_mem and hash_mem_multiplier is clamped to 2GB,
>> thanks
On Sat, Jul 24, 2021 at 06:25:53PM -0700, Andres Freund wrote:
> > That's because they spill to disk where they did not before. The easy
> > answer of "raise hash_mem_multiplier" doesn't help, because on Windows
> > the product of work_mem and hash_mem_multiplier is clamped to 2GB,
> > thanks to
Hi,
On 2021-07-23 17:15:24 -0400, Tom Lane wrote:
> Per the discussion at [1], users on Windows are seeing nasty performance
> losses in v13/v14 (compared to prior releases) for hash aggregations that
> required somewhat more than 2GB in the prior releases.
Ugh :(.
> That's because they spill
Per the discussion at [1], users on Windows are seeing nasty performance
losses in v13/v14 (compared to prior releases) for hash aggregations that
required somewhat more than 2GB in the prior releases. That's because
they spill to disk where they did not before. The easy answer of "raise
13 matches
Mail list logo
