On 05.11.2020 02:53, James Coleman wrote:
On Tue, Nov 3, 2020 at 4:42 PM Tomas Vondra
wrote:
On Tue, Nov 03, 2020 at 03:53:53AM +0100, Tomas Vondra wrote:
Hi,
I took another look at this, and 99% of the patch (the fixes to sort
debug messages) seems fine to me. Attached is the part I plan to
On Tue, Nov 3, 2020 at 4:42 PM Tomas Vondra
wrote:
>
> On Tue, Nov 03, 2020 at 03:53:53AM +0100, Tomas Vondra wrote:
> >Hi,
> >
> >I took another look at this, and 99% of the patch (the fixes to sort
> >debug messages) seems fine to me. Attached is the part I plan to get
> >committed, including c
On 11/4/20 10:58 PM, David Rowley wrote:
On Wed, 4 Nov 2020 at 10:42, Tomas Vondra wrote:
IMHO this should simply switch the current int64 variable to long, as it
was before. Not sure about about the hashagg uint64 variable.
IMO, we should just get rid of the use of "long" here. As far as
On Wed, 4 Nov 2020 at 10:42, Tomas Vondra wrote:
> IMHO this should simply switch the current int64 variable to long, as it
> was before. Not sure about about the hashagg uint64 variable.
IMO, we should just get rid of the use of "long" here. As far as I'm
concerned, using long in the core code
On Tue, Nov 03, 2020 at 03:53:53AM +0100, Tomas Vondra wrote:
Hi,
I took another look at this, and 99% of the patch (the fixes to sort
debug messages) seems fine to me. Attached is the part I plan to get
committed, including commit message etc.
I've pushed this part. Thanks for the patch, Ha
Hi,
I took another look at this, and 99% of the patch (the fixes to sort
debug messages) seems fine to me. Attached is the part I plan to get
committed, including commit message etc.
The one change I decided to remove is this change in tuplesort_free:
- longspaceUsed;
+
On Wed, Oct 21, 2020 at 06:06:52AM +, Tang, Haiying wrote:
Hi
Found one more place needed to be changed(long -> int64).
Also changed the output for int64 data(Debug mode on & define EXEC_SORTDEBUG )
And, maybe there's a typo in " src\backend\executor\nodeIncrementalSort.c" as
below.
Obvi
g
-Original Message-
From: Tang, Haiying
Sent: Monday, October 19, 2020 12:57 PM
To: David Rowley ; James Coleman
Cc: pgsql-hack...@postgresql.org
Subject: RE: Use of "long" in incremental sort code
Hi
Found one more place needed to be changed(long -> int64).
Also change
Hi
Found one more place needed to be changed(long -> int64).
Also changed the output for int64 data(Debug mode on & define EXEC_SORTDEBUG )
And, maybe there's a typo in " src\backend\executor\nodeIncrementalSort.c" as
below.
Obviously, the ">=" is meaningless, right?
- SO1_printf
On Sat, 1 Aug 2020 at 02:02, James Coleman wrote:
> I'd previously attached a patch [1], and there seemed to be agreement
> it was reasonable (lightly so, but I also didn't see any
> disagreement); would someone be able to either commit the change or
> provide some additional feedback?
It looks f
On Thu, Jul 30, 2020 at 10:12 PM David Rowley wrote:
>
> On Fri, 3 Jul 2020 at 07:47, James Coleman wrote:
> > Patch using int64 attached.
>
> I added this to the open items list for PG13.
>
> David
I'd previously attached a patch [1], and there seemed to be agreement
it was reasonable (lightly
On Fri, 3 Jul 2020 at 07:47, James Coleman wrote:
> Patch using int64 attached.
I added this to the open items list for PG13.
David
On Thu, Jul 2, 2020 at 12:47 PM James Coleman wrote:
> But wouldn't that mean we'd get int on 32-bit systems, and since we're
> accumulating data we could go over that value in both memory and disk?
>
> My assumption is that it's preferable to have the "this run value" and
> the "total used across
James Coleman writes:
> On Thu, Jul 2, 2020 at 3:39 PM Tom Lane wrote:
>> mumble ssize_t mumble
> But wouldn't that mean we'd get int on 32-bit systems, and since we're
> accumulating data we could go over that value in both memory and disk?
Certainly, a number that's meant to represent the amo
On Thu, Jul 2, 2020 at 12:44 PM Tom Lane wrote:
> > That's from POSIX, though. I imagine MSVC won't be happy (surprise!).
>
> We've got quite a few uses of it already, so apparently it's fine.
Oh, looks like we have a compatibility hack for MSVC within
win32_port.h, where ssize_t is typedef'd to
On Thu, Jul 2, 2020 at 3:39 PM Tom Lane wrote:
>
> Peter Geoghegan writes:
> > On Thu, Jul 2, 2020 at 10:53 AM James Coleman wrote:
> >> Do you think it's reasonable to use int64 across the board for memory
> >> and disk space numbers then? If so, I can update the patch.
>
> > Using int64 as a r
Peter Geoghegan writes:
> On Thu, Jul 2, 2020 at 12:39 PM Tom Lane wrote:
>> mumble ssize_t mumble
> That's from POSIX, though. I imagine MSVC won't be happy (surprise!).
We've got quite a few uses of it already, so apparently it's fine.
regards, tom lane
On Thu, Jul 2, 2020 at 12:39 PM Tom Lane wrote:
> mumble ssize_t mumble
That's from POSIX, though. I imagine MSVC won't be happy (surprise!).
--
Peter Geoghegan
Peter Geoghegan writes:
> On Thu, Jul 2, 2020 at 10:53 AM James Coleman wrote:
>> Do you think it's reasonable to use int64 across the board for memory
>> and disk space numbers then? If so, I can update the patch.
> Using int64 as a replacement for long is the safest general strategy,
mumble s
On Thu, Jul 2, 2020 at 10:53 AM James Coleman wrote:
> Do you think it's reasonable to use int64 across the board for memory
> and disk space numbers then? If so, I can update the patch.
Using int64 as a replacement for long is the safest general strategy,
and so ISTM that it might be worth doing
On Thu, Jul 2, 2020 at 1:36 PM Peter Geoghegan wrote:
>
> On Mon, Jun 29, 2020 at 9:13 PM David Rowley wrote:
> > I noticed the incremental sort code makes use of the long datatype a
> > few times, e.g in TuplesortInstrumentation and
> > IncrementalSortGroupInfo.
>
> I agree that long is terrible
On Mon, Jun 29, 2020 at 9:13 PM David Rowley wrote:
> I noticed the incremental sort code makes use of the long datatype a
> few times, e.g in TuplesortInstrumentation and
> IncrementalSortGroupInfo.
I agree that long is terrible, and should generally be avoided.
> Maybe Size would be better for
On Tue, Jun 30, 2020 at 7:21 AM Peter Eisentraut
wrote:
>
> On 2020-06-30 06:24, David Rowley wrote:
> > On Tue, 30 Jun 2020 at 16:20, Tom Lane wrote:
> >> There is a fairly widespread issue that memory-size-related GUCs and
> >> suchlike variables are limited to represent sizes that fit in a "lo
On 2020-06-30 06:24, David Rowley wrote:
On Tue, 30 Jun 2020 at 16:20, Tom Lane 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
On Tue, 30 Jun 2020 at 16:20, Tom Lane 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. B
David Rowley writes:
> I noticed the incremental sort code makes use of the long datatype a
> few times, e.g in TuplesortInstrumentation and
> IncrementalSortGroupInfo. (64-bit windows machines have sizeof(long)
> == 4). I understand that the values are in kilobytes and it would
> take 2TB to ca
Hi,
I noticed the incremental sort code makes use of the long datatype a
few times, e.g in TuplesortInstrumentation and
IncrementalSortGroupInfo. (64-bit windows machines have sizeof(long)
== 4). I understand that the values are in kilobytes and it would
take 2TB to cause them to wrap. Never-the
27 matches
Mail list logo
