Observing a common error in Freeradius with Postgres but not justification why it happens

[Alan DeKok]

On Sep 2, 2023, at 10:42 AM, Ibrahim Al Mahfooz <ibrahim.nezar at sevennet.net> wrote:
> By the way, true my queries are customized but not big deal of
> customization. In fact i just removed the non used columns and they are the
> ones that have nothing to do with the where clauses or indexes, hence you
> can consider no change in your original optimized design.

  OK.  It's better to say that up front, instead of saying you "customized" acctuniqueid, etc. columns.  It's not clear at all what that means.

> Any reference article on how to optimize postgresdb for freeradius or
> generic guidelines you believe useful to start with?

  I've given guidelines already.

  There are any number of documentation pages explaining how to optimize Postgres.  There's no interaction with FreeRADIUS which makes it special.  It's all just fixing the database.

> Since I have only two NAS's then I will set it to 512 in this case? Fair
> enough?

  You're better off setting it higher than lower.  There is no impact to setting it higher.

  The default value is fine, unless your database is too slow.  Changing max_requests won't make the database faster.

  Just leave the defaults along.  If they're not causing problems, they're fine.

> Again, I haven't made a skeleton change in the default queries, just
> removed unused columns. The indexes, and columns that are involving where
> clause is left intact. If you have a quick look at the custom queries you
> can tell, actually they are very minimal, the goal of this change is to
> reduce the size of stored bits in the table and also since they won't be
> used, why we store them.

  So you're doing micro-optimizations on things which don't affect performance, but you're running into performance issues.

  Stop wasting your time poking at irrelevant things when the database is on fire.  Fix the database first.  Then worry about the details.

  Alan DeKok.