Question

Ok I know the basics about when indexing should be used and the pros and cons of using it.

These are the (only) two ways my queries will look like:

SELECT target_id FROM map WHERE table_name = '' AND fingerprint = '' AND source_id = 1;

and

SELECT fingerprint, source_id FROM map WHERE table_name = '' AND target_id = 1;

I know I have to index fields table_name, fingerprint and source_id going by first query. Also target_id going by the second query. I can do that individually. But I have heard composite keys give better performance if I could index all the fields as one. Since my case is so specific that there wont be another WHERE clause, I thought of creating composite keys like this:

(table_name, fingerprint, source_id)

and

(table_name, target_id)

But since table_name overlaps in both composite indexing, I am unsure if that’s the way to go. Are there performance implications with such overlapping?

When I did some testing, I did not get any performance improvements with either, both were equally fast.I have about only few tens of thousands of records right now, may be thats the reason. But data will scale to millions of records. So I thought of getting expert opinion on it. Thanks.

Answer 1

In terms of the queries that you’re trying to run, the two indexes that you have are the correct ones. However, I’m not sure about indexing on the table_name field. Indexes on VARCHAR fields tend to be very slow (this answer refers to PostgreSQL, but the underlying concept is the same) and can swell the size of your database, while making INSERTs much slower.

The solution that I use is to create a lookup table, and if I need a query that will give me the VARCHAR fields, I just run a JOIN on the lookup table. JOINs on INTs tend to be fairly fast and scalable.