Ron Johnson <ron.l.john...@cox.net> posted 4a4cf8fc.8030...@cox.net, excerpted below, on Thu, 02 Jul 2009 13:14:20 -0500:
> Because giganews has such a long retention period, some groups can have > a very *large number* of messages. If you subscribe to two or more of > them, you could run out of memory. > > As it is, pan seems to sequentially scan thru all messages when marking > a group of them as Read. > > There needs to be a better and less memory intensive method of handling > huge groups. B-trees, hash tables, SQL-Lite, I don't know, but > *something* better than the status quo. This is true, tho pan is far better than it used to be (it deals with multi-million messages now, where old-pan had problems with 100k). BTW, for 32-bit users at least (I'm not sure if the number is 32-bit or 64-bit for 64-bit users), at least one group on Giganews has "rolled over" the 32-bit article sequence integer pan uses. It needs to be a 64- bit number, or at least 33-bit. More groups will follow over time. AFAIK there's a patch floating around to allow pan to deal with this, but it hasn't been applied in mainline yet. Just a heads-up. Giganews has articles covering it on their website, I believe. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
