Very interesting. I think I might be hitting the same issue as you had with a join between two fairly large tables. I think that nothing else explains the speed issues I'm facing, and why PostgreSQL's planner is ignoring the indices I do have. Care to elaborate a bit more on this point?
The way of putting this key manually on the SQL level varies by developer, I'll leave it to you. I did it with putting custom logic into my apps.py on the module that contains the models.py, which will execute on Django checks (and local runserver).
Dare to say "dick measuring contest" on this site and you get a warning for supposedly offending someone who doesn't have one? lol. Goes to show the snowflakeness of this site.
In my apps.py under the django module that contains the models.py with the model, I added the following functions, which is a result of me experimenting around until I found out the right way of doing it. It is basically putting together the SQL for creating the index via MariaDB:
fromdjango.appsimportAppConfigfromdjango.confimportsettingsfromdjango.core.checksimportInfo,Tags,registerfromdjango.dbimportconnectionfromdjango.db.models.signalsimportpost_migratefromdjango.db.utilsimportOperationalErrorfromdjango.utils.translationimportugettext_lazyas_defadd_applieddiscount_sr_index()->list:"""
As discussed in the link below, add an index to `seatreservation_id`
on the `ManyToMany` `AppliedDiscount` relation.
https://dev.to/karolyi/django-why-you-might-want-to-set-up-extra-db-level-indexes-for-your-manytomany-relationships-1ecg
"""from.modelsimportSeatReservationerrors=[]m2m_model=SeatReservation.applied_discounts.throughdb_table=m2m_model._meta.db_tablefield_name=m2m_model._meta.get_field('seatreservation').columncursor=connection.cursor()try:cursor.execute(f'ALTER TABLE `{db_table}` ADD INDEX sr_id_index (`{field_name}`)')exceptOperationalErrorasexc:ifexc.args[0]==settings.MARIADB_INDEX_ALREADY_EXISTS_CODE:# Index already exists
returnerrorsraiseerrors.append(Info(msg='Added index on SeatReservation.applied_discounts'))returnerrorsdefpost_migrate_ensure_defaults(**kwargs):"""
Run the default models installer when it is our application's
`post_migrate` signal.
"""ifnotisinstance(kwargs['sender'],BookingConfig):# Running from migration post-signal, but not from our app's
# signal
returnreturnensure_defaults()defensure_defaults(**kwargs):'Run the default setter and maintenance functions.'errors=[]errors.extend(add_applieddiscount_sr_index())returnerrorsclassBookingConfig(AppConfig):name=f'project.booking'verbose_name=_('Project: Booking')label=f'project_booking'defready(self):'Fix database, run maintenance scripts, etc ...'post_migrate.connect(post_migrate_ensure_defaults,dispatch_uid=f'{self.label}.ensure_defaults')register(ensure_defaults,Tags.models)
Also, you'll have to modify the init.py next to the apps.py to contain the following lines:
Very interesting. I think I might be hitting the same issue as you had with a join between two fairly large tables. I think that nothing else explains the speed issues I'm facing, and why PostgreSQL's planner is ignoring the indices I do have. Care to elaborate a bit more on this point?
Oh, I almost forgot to reply to you.
In my apps.py under the django module that contains the models.py with the model, I added the following functions, which is a result of me experimenting around until I found out the right way of doing it. It is basically putting together the SQL for creating the index via MariaDB:
Also, you'll have to modify the init.py next to the apps.py to contain the following lines:
Where the path in default_app_config is the python import path to your apps.py.