pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: Better processing of very large groups?


From: Duncan
Subject: [Pan-users] Re: Better processing of very large groups?
Date: Thu, 2 Jul 2009 23:53:53 +0000 (UTC)
User-agent: Pan/0.133 (House of Butterflies)

Ron Johnson <address@hidden> posted
address@hidden, 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]