> On Wed, Jun 07, 2006 at 11:47:45AM -0400, Tom Lane wrote:
>> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> > Koichi Suzuki wrote:
>> >> I've once proposed a patch for 64bit transaction ID, but this causes
>> >> some overhead to each tuple (XMIN and XMAX).
>>
>> > Did you check performance on 32-bit or 64-bit systems and 64-bit
>> binary
>> > version of PGSQL? I think that today is not problem to have 64-bit
>> > architecture and 64-bit ID should increase scalability of Postgres.
>>
>> The percentage increase in I/O demand is the main reason the patch was
>> rejected, not so much the arithmetic.
>
> Before considering 64 bit XIDs, it'd be very helpful to know why Mark
> can't vacuum frequently enough to handle rollover...
The system is under heavy load, and while there are tricks that can be
done, vacuum is a process which is extra load the system when it is
running. It is a sliding scale, as always, you may get the system to the
point where it can vacuum AND perform as needed, but the database is
growing constantly. Eventually you will get to the point where you can't
run vacuum *and* keep up with the data stream.
I guess what I am saying is that PostgreSQL isn't "smooth," between
checkpoints and vacuum, it is near impossible to make a product that
performs consistently under high load.
Now don't flame me, I really do love PostgreSQL, it is just that I bump up
against these issues from time to time and it would be nice if there were
some way to work around them.