Runtime performance of fetch commands for PostgreSQL

I was reading this answer for why there is no fetch by contract key ledger API and that it has to scan all active contracts to do so.

I am wondering, when executing Daml choices, what is the performance standard Daml read/write operations both on contract ids (like for fetch or exercise) and on contract keys (like on fetchByKey)?

Specifically, are these lookups done via indexes in PostgreSQL or do they involve potential O(n) scans?

If I read the post correctly, it describes how the HTTP JSON API service works around the lack of fetch commands over the Ledger API, not why those are not available in the first place.

Contracts are indexed by their ID and (if present) by their key, making those operations as fast as they can possibly be when the Daml engine asks for them. The usage of that index is of course up to the database itself, but given the indexes I cannot imagine a normal situation where those would not be picked up.

Thanks for the response here, @stefanobaghino-da and confirming that the Daml operations are indeed as efficient as they can be!

Indeed, it’s about the JSON API service, but my thinking was that perhaps the fetch-by-key operations were not that efficient so that’s why they are not exposed on the ledger API. So I wanted to double check that (for the Postgres case at least) they are efficient.