For simple equality checks (=), a B-Tree index on a varchar or text column is simple and the best choice. It certainly helps performance a lot. And a UNIQUE constraint (like you mentioned) is already implemented with such an index, so you would not create another one.
Of course, a B-Tree index on a simple integer performs better. For starters, comparing simple integer values is a bit faster. But more importantly, performance is also a function of the size of the index. A bigger column means fewer rows per data page, means more pages have to be read …
Since the HomeAddress is hardly unique anyway, it’s not a good natural primary key. I would strongly suggest to use a surrogate primary key instead. A serial column or IDENTITY in Postgres 10+ is the obvious choice. Its only purpose is to have a simple, fast primary key to work with.
If you have other tables referencing said table, this becomes even more efficient. Instead of duplicating a lengthy string for the foreign key column, you only need the 4 bytes for an integer column. And you don’t need to cascade updates so much, since an address is bound to change, while a surrogate PK can stay the same (but doesn’t have to, of course).
Your table could look like this:
CREATE TABLE resident (
resident_id serial PRIMARY KEY
, address text NOT NULL
-- more columns
);
CREATE INDEX resident_adr_idx ON resident(address);
This results in two B-Tree indexes. A unique index on resident_id (implementing the PK) and a plain index on address.
Postgres offers a lot of options – but you don’t need any more for this simple case. See:
- The manual about indexes