If you are doing an order by on a single table on an indexed column, is that expensive? If you are doing an order by on a clustered index, wouldn't the order by be essentially free?
But I never thought about it, but it does make perfect sense to sort on the app server and filter on the database. When hosted locally, it's practically nothing in terms of money, time to spin up another API server and add it to the load balancer compared to another SQL Server instance.
If you are doing an order by on a single table on an indexed column, is that expensive?
No, but it sure is unusual. I don't know a lot of folks who only reference a single table in their queries. (Folks who do are generally using key/value stores, not RDBMS's.)
If you are doing an order by on a clustered index, wouldn't the order by be essentially free?
Assuming you're using an identity (sequential) field, that's also incredibly unusual. The clustering key rarely has value to the select query.
Comments
If you are doing an order by on a single table on an indexed column, is that expensive? If you are doing an order by on a clustered index, wouldn't the order by be essentially free?
But I never thought about it, but it does make perfect sense to sort on the app server and filter on the database. When hosted locally, it's practically nothing in terms of money, time to spin up another API server and add it to the load balancer compared to another SQL Server instance.
No, but it sure is unusual. I don't know a lot of folks who only reference a single table in their queries. (Folks who do are generally using key/value stores, not RDBMS's.)
Assuming you're using an identity (sequential) field, that's also incredibly unusual. The clustering key rarely has value to the select query.