What is the lowest weight direct consultation or using views for a double relationship?

Question

Given the following schema hypothetical:

create table cidade(
  cidade_id integer primary key not null,
  nome varchar(40)
);

create table envios(
   id integer primary key not null,
   cidade_origem_id  integer,
   cidade_destino_id integer
);
alter table envios add foreign key (cidade_origem_id) references cidade (cidade_id);
alter table envios add foreign key (cidade_destino_id) references cidade (cidade_id);

insert into cidade values (1, 'Barbacema');
insert into cidade values (2, 'Los Angeles');
insert into cidade values (3, 'São Paulo');
insert into cidade values (4, 'Porto Velho');

insert into envios values (1, 1,2);
insert into envios values (2, 2,3);
insert into envios values (3, 3,4);

create view cidade_origem as select * from cidade;
create view cidade_destino as select * from cidade;

To find shipments by origin and destination I have the following query:

select co.nome origem, cd.nome destino from envios e
inner join cidade co on co.cidade_id = e.cidade_origem_id
inner join cidade cd on cd.cidade_id = e.cidade_destino_id

What would weigh more? Leave the query as is or use two views (one for the city of origin and one for the city of destination), and joins with these views?

select co.nome origem, cd.nome destino from envios e
inner join cidade_origem co on co.cidade_id = e.cidade_origem_id
inner join cidade_destino cd on cd.cidade_id = e.cidade_destino_id

Answer 1

I don’t see the need to create any VIEW in your case. And, indeed, the creation of a VIEW not materialized could further degrade performance.

For example, even if you specify the clause WHERE for a consultation on VIEW that you called cidade_origem, "under the table", a SELECT * FROM envios; is being executed.

My suggestion is that you continue with your JOINS and create indexes in the fields cidade_origem_id and cidade_destino_id on the table envios:

CREATE INDEX idx_envios_cidade_origem ON envios (cidade_origem_id);
CREATE INDEX idx_envios_cidade_destino ON envios (cidade_destino_id);

Attention, the PostgreSQL creates implicit clues in primary keys, but does not do the same in input keys.

Another golden hint is to avoid "guessing" where there will be bottlenecks. Bottlenecks need to be detected and identified, only then to think about optimizations. You did what the "good practices" told you, now hold on the throats are screaming.