On Thu, Mar 27, 2003 at 06:07:04PM +0100, Thomas Corell wrote:
Nick Reinking wrote:
On Thu, Mar 27, 2003 at 06:36:29AM +0100, Thomas Corell wrote:
Oh, they call that an extention. Well. There's a serial/serial8 type in Postgres, which implicitly creates a sequence and you can use the functions nextval() and currval(). So a definition of e.g. "cur_id serial8 PRIMARY KEY" should handle this.
Or just serial, which would be considerably faster than serial8, unless you think that you will end up with more than 2147483648 rows (2^31).
Only to meassure my expectations for wikipedia ;) But keep in mind that reusing serials is not part of the pg concept, but as far as I know mysql does. E.g. deleting articles may spend a serial.
Fair enough, I do believe you're right. Still, deleted articles are not terribly common, and I think we should design this with maximum performance in mind. If we hit some odd 1.8B articles in the future, we can always figure out a way to change it to serial8. :)
Speaking of maximum performance... I have a question concerning our implementation. What will be more important in the future, clean and efficient code, or backwards compatibility? Especially when you consider the reverse_timestamp hacks everywhere that won't be needed in MySQL4 (or PostgreSQL), I would think that we should just drop MySQL3 support (especially considering that it is easy to upgrade, and nobody will be using it in a year or two). But, maybe I'm crazy - anybody else have any comments?