perf: add indexes for Login filter fields

[nishantxscooby]

Fixes #494

Improve Login query performance by adding DB indexes

Problem
Queries on the Login model were causing sequential scans when filtering by
timestamp, ip, country, and event_id, leading to poor performance on large datasets.

Solution
Add database indexes for the most commonly filtered fields in Login:

• timestamp
• ip
• country
• event_id

The index field is intentionally not indexed, as previously discussed.

Scope

• Login model only
• Single migration
• No unrelated file changes

[nishantxscooby]

Hi @Lorygold

This change only adds database indexes on the fields involved in the reported Seq Scan (timestamp, ip, country, event_id).
Since BuffaLogs is a Django app package (not a standalone project), I validated the fix by ensuring the migration cleanly adds the intended indexes in a single migration and avoids the index field as previously discussed.

Let me know if you prefer a different indexing strategy, ty :)

[Lorygold]

in addition to that, I was wondering that the Login.ip field could be changed in a models.GenericIPAddressField() type, as done for the UsersIP.ip field for improving performances, what do you think about that?

in that case, a new test in the test_migrations.py file should be added and a custom function at the beginning of the migration (as done in the 0022 migration, for example) for deleting the existing logs in the Login model that hasn't a valid IP (IPv4 or IPv6) in the Login.ip field

[Lorygold]

Could be nice to add also the dkango-debug-toolbar and attaching the prove of query improvements

[Lorygold]

I don't remember if the event_id is queried somewhere? Because if not, its indexing is useless

[Lorygold]

If I remember well, the timestamp is often queried as the inverse order:
.order_by("-timestamp")
so, it could be usefull to index it as "-timestamp"
what do you think?

[Lorygold]

You should double-check whether these indexes actually match the way queries are executed and prove their match

For example, country is often queried with __iexact (case-insensitive), which does UPPER(country) = UPPER(value) in SQL.

A plain index on country won’t be used in this case; for it to help, you’d need a functional index like models.Index(Upper("country"), name="login_country_upper_idx").