Re: Big performance slowdown from 11.2 to 13.3

Em qui., 22 de jul. de 2021 às 14:28, Peter Geoghegan <pg(at)bowt(dot)ie> escreveu:

> On Thu, Jul 22, 2021 at 10:11 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > No, he already tried, upthread. The trouble is that he's on a Windows
> > machine, so get_hash_mem is quasi-artificially constraining the product
> > to 2GB. And he needs it to be a bit more than that. Whether the
> > constraint is hitting at the ngroups stage or it's related to actual
> > memory consumption isn't that relevant.
>
> Somehow I missed that part.
>
> > 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.
>
> +1. Even if we assume that Windows is a low priority platform, in the
> long run it'll be easier to make it more like every other platform.
>
> The use of "long" is inherently suspect to me. It signals that the
> programmer wants something wider than "int", even if the standard
> doesn't actually require that "long" be wider. This seems to
> contradict what we know to be true for Postgres, which is that in
> general it's unsafe to assume that long is int64. It's not just
> work_mem related calculations. There is also code like logtape.c,
> which uses long for block numbers -- that also exposes us to risk on
> Windows.
>
> 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.
>
I wonder if similar issues not raise from this [1].

(b/src/backend/optimizer/path/costsize.c)
cost_tuplesort uses *long* to store sort_mem_bytes.
I suggested switching to int64, but obviously to no avail.

+1 to switch long to int64.

regards,
Ranier Vilela

[1]
https://www.postgresql.org/message-id/CAApHDvqhUYHYGmovoGWJQ1%2BZ%2B50Mz%3DPV6bW%3DQYEh3Z%2BwZTufPQ%40mail.gmail.com