Add index for CRUDEvent.datetime

[GigiusB]

In our scenario we have 1.7M records in the table (postgres DB)

By indexing the field CRUDEvent.datetime the following query performed in the admin goes from 38seconds down to <0.5sec

SELECT "easyaudit_crudevent"."id",
       "easyaudit_crudevent"."event_type",
       "easyaudit_crudevent"."object_id",
       "easyaudit_crudevent"."content_type_id",
       "easyaudit_crudevent"."object_repr",
       "easyaudit_crudevent"."object_json_repr",
       "easyaudit_crudevent"."changed_fields",
       "easyaudit_crudevent"."user_id",
       "easyaudit_crudevent"."user_pk_as_string",
       "easyaudit_crudevent"."datetime"
  FROM "easyaudit_crudevent"
 ORDER BY "easyaudit_crudevent"."datetime" DESC, "easyaudit_crudevent"."id" DESC
 LIMIT 100

[jheld]

I do understand this scenario. I'm not going to say it's unimportant. I'm very well acquainted with it and in some cases have been able to get around it.

The problem as I see it is that it appears to be only come about through access via the django admin.

Perhaps if we removed the default ordering of -datetime people would be less likely to be initially hit by this.

I wonder if potentially encouraging people to use the ModelAdmin's configurability via https://docs.djangoproject.com/en/4.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.ordering would encourage other solutions.

So for instance, when you're doing a search on django admin, what are you likely to be looking for? Is it really just for items descending order by time, or more likely items in a certain object_type/object_id instead (and ordered by time)?

In the end we may have to allow this change (the devil's advocate was that I felt a bit cautious with regards to the incorrect index being chosen on certain queries, and thus scenarios where this would be slowdowns that you would not expect, given the additional index being in place).