Is it possible to disable all locks for a specific table in any version of SQL Server?
I have a handful number of tables that are populated with data at deployment time. For example, one of the smaller tables,
'Blue', 'Green', 'Red', 'White'. After deployment, the application(s) only ever select from these tables (never insert, update, or delete). I got to thinking, if these tables are only ever read from, then what is the point of having locks? I assume it takes some amount of time to get a lock. Even if that amount of time turns out to be negligible, part of me won't be satisfied until I test the difference myself.
As I searched for the answer on my own, I discovered that I can mark an entire database as read-only, and that there may be some benefits. I want those benefits, but on a table-by-table basis. I also read about disabling lock-escalation, but if I understood the documentation correctly, that would only lead to more (albeit finer-grained) locks, which is the opposite what I want to achieve.
I know that I can update every single query that uses the table to have a
NOLOCK hint, but that introduces a secondary problem. In the future when I teach my application how to learn new
Colours at runtime, do I want to go update every query that uses the table to remove the
NOLOCK hint? That sounds like a hassle.
It seems the question is receiving a few downvotes, and without any explanation provided, I'm going to assume that it's because this seems like what I'm asking for is premature optmization. Premature optimization is, as pointed out in a now deleted comment, the root of all evil. I know that, and I'm not prematurely optimizing. Here's why.
I'm allowed to poll this API once per second. It's not stated on the linked page, but I saw the rule somewhere (trust me). Anyway, it takes my application anywhere from 100ms to 800ms to make the HTTP request, download the gzip'd text file, and unzip it. Most of this time is spent waiting on the API for a response. That leaves me with hardly any time at all for processing all of the data into nice, neat, normalized database tables. If I'm to be competitive, I have to process all of the data in 200ms or less. I'm so close to achieving my goal that I'm cutting corners by discarding data I might not need, sending all of the data to the database at once in one big ugly bundle, etc. So yes, I am optimizing, but not prematurely (in my opinion).
I also recognize that what I'm asking for may have no performance benefits. In fact, the one solution that has been provided so so far didn't seem to affect performance at all. I couldn't have known that before I asked the question though, and now any future visitors who are wondering if this will help them can see the test I performed and know that it isn't worth it. Isn't that useful?
If this doesn't address whatever the downvoters' concerns are, please consider leaving a comment with what you think I could improve about the question.