Ivan Kalik wrote:
Nothing in freeradius. But on the database side? Radacct is a big chunk as
it is. Most people keep at least 3 months worth of data and than can be
quite a few GB. There is significant impact on database performance at the
time of daily backup. Proposed changes would increase radacct size by
10-20%. That's a few more minutes of poorly responsive database.
This may be true for other DBs, for it's not for postgres:
http://www.nabble.com/Re%3A-Disadvantages-to-using-"text"-p17109220.html
I'm only suggesting changing the postgres schema. I realise the OP may
not have been using postgres - this is a bit of a digression on my part.
Obviously if you're actually *putting* more data in the fields the table
would get bigger, but the alternative is either a failed or truncated
insert. The former is a pretty big deal, and the latter is at best very
confusing.
Increasing field sizes to 250 characters when huge majority of people
would do fine with only one tenth of that field is not a very good design
solution. Perhaps adding a second schema where these fields are maxed up
(large_fields_schema.sql)?
PS. I must appologize, it was not my intention to imply that if your
;o) No probs
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
