Just in case you thought you’d slip the most subtle of bangers out there and nobody would see….

I blame Dave for his lack of foresight.

Hand finally healed from the last button and now there’s another one?

Should have done it in Quebec. 18 there.

I don’t think they’re calling me back. I’d save them too much money.

Ok - had to look that up. I’m an Old. :)

I’d see whether there’s a way to convince it to return the record with the max timestamp that meets your criteria. If you know you only want one and it’s always the newest, it might work better.

Could also select the record from that memory table with the max timestamp and avoid the limit altogether.

I think if your basic query would be relatively selective in prod (say 5k rows or less), you’re probably faster overall to just select * from (select whatever uses your index order by timestamp desc) limit 1.

Not as pretty but likely uses your index and executes faster.

What is the value of the count vs the limit?

“Get an explain plan for the query….”

Question will be whether that limit value is too high for whatever is receiving your files.

Ok - so you’re pulling data based on a set of indexed values but the query is opting to scan the PK because of the limit.

Maybe start doubling that limit and get an explain plan to n the query. There has to be a point where it’s cheaper to use the index.

Other option - if the LIMIT is monkeying with the optimizer (docs suggest it does), what happens with a larger value?

Another thought - if you are exporting only a subset of the table, create a memory table based on your index columns and then export from that?