This PR has a migration; here is the generated SQL for src/sentry/migrations/1048_organizationmapping_cell_name_idx.py

for 1048_organizationmapping_cell_name_idx in sentry

--
-- Create index sentry_orgmapping_cell_name_date_updated_id_idx on F(cell_name), TruncSecond(F(date_updated)), F(id) on model organizationmapping
--
CREATE INDEX CONCURRENTLY "sentry_orgmapping_cell_name_date_updated_id_idx" ON "sentry_organizationmapping" ("region_name", (DATE_TRUNC('second', "date_updated" AT TIME ZONE 'UTC')), "id");

lgtm. What query are you hoping to use this on btw? Are you wanting to filter to some subset of ids within a second?

this index matches the ordering that SynapsePaginator expects https://github.com/getsentry/sentry/blob/master/src/sentry/synapse/paginator.py

there is already an existing index with (TruncSecond(date_updated), id) but that didn't previously handle the case where we are requesting by a subset of cells (most of the time), hence the addition of this index (cell_name, TruncSecond(date_updated), id)

lgtm. What query are you hoping to use this on btw? Are you wanting to filter to some subset of ids within a second?

this index matches the ordering that SynapsePaginator expects https://github.com/getsentry/sentry/blob/master/src/sentry/synapse/paginator.py

there is already an existing index with (TruncSecond(date_updated), id) but that didn't previously handle the case where we are requesting by a subset of cells (most of the time), hence the addition of this index (cell_name, TruncSecond(date_updated), id)

Got it, so the id is just a tie breaker there. Makes sense.

Since that query is using an OR, it might be worth making sure the index gets used. I've sometimes seen weird behaviour from postgres in those cases, but might not be all that big of a deal here.