IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New I bet a killfile would be more efficient
Rather than marking a thread read, Kill it from my perspective. That way it stays out of my face, and the system only needs to keep track of a list of killed threads/userIDs for each user. And depending on how the list is allocated, it might not even be stored for those who don't use it.
White guys in suits know best
- Pat McCurdy
New The best that you could hope for
In doing this is using an additional byte per user, per thread. Thus if 200 people at one time or another opened an account on this board, and the board reached 1000 threads (easily once in full production), this would increase storage use to 200,000 bytes.

This also assumes that the data is set up so that it would only be a matter of adding a new field, which I seriously doubt. So this would mean adding another table all together which is keyed to both the thread number and user key. This easily increases the size by a multiple of at least 5 (assuming thread and user keys being kept as short integers).

Then you also have to consider the extra time that will be required for this lookup.

It's fine for me as is, though it might speed up users with modems a bit.
~~~)-Steven----
     Gud Schtuffs - (pwhysall) - (6)
         Memory like a sieve - (pwhysall) - (4)
             That might not be possible. - (inthane-chan) - (3)
                 Everything is possible. - (admin) - (2)
                     I bet a killfile would be more efficient - (mhuber) - (1)
                         The best that you could hope for - (Steven A S)
         Re: Gud Schtuffs - (admin)

I love RedBrick, it's the only database I've met than can consistently give different results for
Select count(*) from table
versus
select count(*) from table where 1=1
197 ms