SELECT subject_name
FROM subject
JOIN subject_of_teacher USING (id_subject)
WHERE id_teacher = :ID;
PS. JOIN может быть синтаксически некорректным, ибо струячу по памяти, смотрите документацию: https://postgrespro.ru/docs/postgresql/11/sql-select
ЗЫЫ. Вроде как ошибков нет.
ЗЫЫЫ. Вот, хорошо, когда ссылочный столбец в таблицах одинаково называется. :)

Последнее сарказм?)

Хм... А ведь по через джойн реально проще получается. :)

Не знаю, но я сам предпочитаю таким столбцам давать одно название. Мне так больше нравится.

Довольно быстрый запрос (10ms) время от времени начинает выполняться за 200-300ms. Заспамил select * from pg_locks но поймать момент не смог - запросов много. можно ли как-то убедиться, что дело именно в локах и если да, то каких?

Без самого запроса (и плана запроса) - это гадание если не по кишкам, то по дерьму.

Всем привет
вот в таблице есть ключь
       FOREIGN KEY (payment_token_id) REFERENCES payment_token(id),

ключь на таблицу вот эту:

CREATE TABLE IF NOT EXISTS payment_token (
                        id SERIAL PRIMARY KEY, 
                        PaymentToken_id TEXT, 
                        PaymentToken_creator TEXT,
                        PaymentToken_expdate TEXT, 
                        PaymentToken_type TEXT, 
                        PaymentToken_status TEXT, 
                        PaymentToken_creatorStatus TEXT, 
                        PaymentToken_wallet TEXT, 
                        PaymentToken_deviceType TEXT, 
                        PaymentToken_lang TEXT,
                        PaymentToken_deviceTelNum TEXT, 
                        PaymentToken_deviceIp TEXT, 
                        PaymentToken_deviceId TEXT, 
                        PaymentToken_deviceName TEXT, 
                        PaymentToken_activationCode TEXT, 
                        PaymentToken_activationExpiry TEXT, 
                        PaymentToken_activationMethod TEXT, 
                        PaymentToken_activationMethodData TEXT 
  );

вопрос откуда тогда ошибка: pq: column "payment_token_id" referenced in foreign key constraint does not exist

"payment_token_id" - название колонки, pg ругается, что такой колонки нет

ага, очень помогло: пример 2

 CREATE TABLE IF NOT EXISTS song(  
                        id SERIAL PRIMARY KEY,
                        name_of_song TEXT,
                        album_id INT,
                        genre_id INT,
                        author_id INT,
                        track_number INT,
                        UNIQUE(author_id, album_id, name_of_song),
                        UNIQUE(album_id, track_number),
                        FOREIGN KEY (album_id) REFERENCES album(id),
                        FOREIGN KEY (genre_id) REFERENCES genre(id),
                        FOREIGN KEY (author_id) REFERENCES author(id)

Ни в одной из таблиц накоторые есть foreign key нет таких колонок как album_id, genre_id or author_id но ошибок нет и всё  работает ,

 CREATE TABLE IF NOT EXISTS genre (
                        id SERIAL PRIMARY KEY, 
                        genre_name TEXT UNIQUE
  );`
  
CREATE TABLE IF NOT EXISTS author (
                        id SERIAL PRIMARY KEY, 
                        author_name TEXT UNIQUE
  );`
  CREATE TABLE IF NOT EXISTS album (
                        id SERIAL PRIMARY KEY,
                        author_id INT, 
                        album_name TEXT,
                        album_year INT,
                        cover TEXT, 
                        UNIQUE(author_id, album_name),
                        FOREIGN KEY (author_id) REFERENCES author(id)

album_id INT,
FOREIGN KEY (album_id) REFERENCES album(id),

первая строка - определяется колонка, вторая - настраивается foreign key для этой колонки

Можно перечитать ошибку
pq: column "payment_token_id" referenced in foreign key constraint does not exist

ок , ну вот хорошо что пол года назад работал с этой базой и есть пример работающий спаисбо, повылазило )

По приведенному вами куску sql  могу придеположить, что вы не туда смотрите (колонки нет в создаваемой таблице, а не в той, на которую референс делается)

мой вопрос же не про запрос, а про мониторинг локов. план запроса в порядке, там один index scan и всё

1. Локи для того и нужны, чтобы ждать. Здрасьте. Тут что-то оптимизировать — это как ноги себе отпилить, чтобы быстрее бегать.
2. Постгрес так сделан, что SELECT'у наплевать на локи. MVCC называется.

1. я бы начал с мониторинга утилизации CPU и особенно дисков, гораздо чаще они являются “затыком”
2. мониторить наличие ждущих сессий через pg_stat_activity.wait_event_type='Lock' ( https://github.com/dataegret/pg-utils/blob/master/sql/db_activity9.6.sql )
3. мониторить кто кого блокирует через https://github.com/dataegret/pg-utils/blob/master/sql/locktree.sql

`pg_stat_activity.wait_event_type='Lock'`

вот это тоже спамил, ни разу не поймалось. выше уже объяснили что селекты не блокируют, забыл про это, но всё-равно было б интересно иметь инструмент, который бы  для долгих запросов показывал какие локи они ждали и сколько.

а зачем? если они никого не ждут и никого не блокируют — зачем это знать?

3. Что это такое, что оно должно показывать? Натравил на базу, где лок локом погоняет в 80 параллельных потоков — выводит 0 строк.

ну не для этого конкретного запроса,  а вообще. не всегда ж можно на сервер придти, повторить запрос и получить ту же самую производительность. хочется чтобы оно на месте диагностику собирало, в тот самый момент когда было медленно