Re: number of loaded/unloaded COPY rows

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

In response to

Browse pgsql-hackers by date

  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