From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: number of loaded/unloaded COPY rows |
Date: | 2005-12-17 22:11:14 |
Message-ID: | 10698.1134857474@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I think we are at a point that people running on systems with no int64
> support should not expect to get valid return values for >2 billion row
> COPY operations.
I agree, there's no need to work harder on this than changing the
datatype to uint64.
There are some places (vacuum and index build IIRC) that use "double"
counters instead of either int32 or int64. That was a good compromise
a few years ago, but I'm not sure we still need it. I think we can
reasonably say that our goals for backward-compatibility to systems
with no int64 datatype do not include working nicely with tables
exceeding 4G rows.
I didn't like that the patch introduced new buffer variables that were
not there before --- that is just adding complexity to no point. This
patch should not need to do more than change some variables' datatypes
and adjust printf formats and string buffer lengths to match.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lukas Smith | 2005-12-17 23:28:39 | Re: Automatic function replanning |
Previous Message | Bruce Momjian | 2005-12-17 21:59:45 | Re: [BUGS] Solaris cc compiler on amd: PostgreSQL does not |