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?
--
Nick Reinking -- eschewing obfuscation since 1981 -- Minneapolis, MN