>>>>> "Marc" == Marc Dirix <[EMAIL PROTECTED]> writes:
Marc> All INT8 can be changed into INT4 on small to middle installs. Marc> We have them all INT4 with 10K users. I think dbmail_users.curmail_size and dbmail_users.maxmail_size should remain INT8. 2 Gigs is easy to hit. Otherwise, the big issue is UID and UIDVALIDITY for IMAP users. As long as UID remains unique per install rather than unique per UIDVALIDITY the issue of hitting the 2Gig barrier needs addressing. But anyone that busy should be using a 64bit platform. (In my own case -- using emacs and gnus -- it is a non-issue because nnimap uses emacs' integers for UID and those are currently limited to, IIRC, 29 bits on a 32 bit platform. So I'll be unable to read the mail long before UID maxes out an INT4. Even so, it is unlikely my already old laptop will still run by the time I'd hit UID 2^29 at even an order of magnitude more messages per day. In fact, 32bit time_t will fail first.) I think long long for curmail_size and maxmail_size, and either int or long for everything else should work well. As for the schema, I'd have two: one with just the two INT8s for most users and the current schema for the largest installs. -JimC -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
