Heavy database index on modified field - is it necessary?

[amureki]

Hey @codingjoe !

Thanks again for the package. :)

We're running a Django application using joeflow and noticed that the joeflow_task_modified_a7cae80a index is big (103 MB in our case), making it the heaviest database indexes we have on one of the services.

The number of tasks is not that significant.

DATABASE=> SELECT COUNT(*) FROM joeflow_task;
  count
---------
 2496686
(1 row)

So one question I had, Is the index on the modified field actually needed for joeflow's internal operations?
I am not sure about your opinion on the indexes in this package (overall, joeflow has quite a lot of them leading the table of records, haha), is this something we can iterate on?

Cheers,
Rust

[codingjoe]

Hi @amureki 👋,

Since those fields are usually used for sorting, I presume a default index isn't a bad idea. You could also make a case to drop the field entirely. Yet, since storage is fairly cheap these days, I would error on the side of caution. However, if you are experiencing performance issues because you are processing so many tasks that the index write is throttling your database, you can simply drop the index. Django won't complain 🤷; it won't even know.

FYI: For your restore, you can also exclude the table from being restored. As I have shown with emark.

I hope this help.

Best
Joe