On Thu, Jul 2, 2020 at 1:36 PM Peter Geoghegan <p...@bowt.ie> wrote: > > On Mon, Jun 29, 2020 at 9:13 PM David Rowley <dgrowle...@gmail.com> 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 the in-memory fields and uint64 for the > > on-disk fields? > > FWIW we have to use int64 for the in-memory tuplesort.c fields. This > is because it must be possible for the fields to have negative values > in the context of tuplesort. If there is going to be a general rule > for in-memory fields, then ISTM that it'll have to be "use int64". > > logtape.c uses long for on-disk fields. It also relies on negative > values, albeit to a fairly limited degree (it uses -1 as a magic > value).
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. James
