Почему postgresql выбирает неоптимальный план выполнения для простого JOIN?

Question

[che_aa]

Вопрос аналогичен Почему PostgreSQL использует неоптимальный план выполнения для простого запроса? но решение там не помогло.

У меня есть простая таблица:

Table "public.friends_info"
     Column      |  Type  | Collation | Nullable | Default
-----------------+--------+-----------+----------+---------
 user_id         | bigint |           |          |
 friend_id       | bigint |           |          |
 unix_time_check | bigint |           |          |
Indexes:
    "friends_info_user_id_friend_id_key" UNIQUE CONSTRAINT, btree (user_id, friend_id)
    "ix_friends_friend_id" btree (friend_id)
    "ix_friends_user_id" btree (user_id)

Я выполняю 2 одинаковых запроса, но postgresql выбирает 2 разных плана выполнения:

EXPLAIN (ANALYZE,BUFFERS) SELECT * FROM friends_info LEFT JOIN i ON friends_info.friend_id = i.user_id WHERE friends_info.user_id = 1;
                                                                 QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1063.49..41700.28 rows=5465 width=644) (actual time=3.039..18.789 rows=88 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   Buffers: shared hit=447 read=1
   ->  Nested Loop Left Join  (cost=63.49..40153.78 rows=2277 width=644) (actual time=0.657..2.055 rows=29 loops=3)
         Buffers: shared hit=447 read=1
         ->  Parallel Bitmap Heap Scan on friends_info  (cost=62.92..20715.73 rows=2277 width=24) (actual time=0.621..0.629 rows=29 loops=3)
               Recheck Cond: (user_id = 1)
               Heap Blocks: exact=1
               Buffers: shared hit=7 read=1
               ->  Bitmap Index Scan on ix_friends_user_id  (cost=0.00..61.56 rows=5465 width=0) (actual time=0.742..0.743 rows=88 loops=1)
                     Index Cond: (user_id = 1)
                     Buffers: shared hit=6 read=1
         ->  Index Scan using total on i (cost=0.57..8.54 rows=1 width=620) (actual time=0.046..0.046 rows=1 loops=88)
               Index Cond: (user_id = friends_info.friend_id)
               Buffers: shared hit=440
 Planning:
   Buffers: shared hit=242
 Planning Time: 2.748 ms
 Execution Time: 18.919 ms
(20 rows)

EXPLAIN (ANALYZE,BUFFERS) SELECT * FROM friends_info LEFT JOIN i ON friends_info.friend_id = i.user_id WHERE friends_info.friend_id= 1;
                                                                 QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------
 Nested Loop Left Join  (cost=1.14..85.73 rows=18 width=644) (actual time=0.267..0.892 rows=28 loops=1)
   Join Filter: (friends_info.friend_id = i.user_id)
   Buffers: shared hit=37
   ->  Index Scan using ix_friends_friend_id on friends_info  (cost=0.57..76.88 rows=18 width=24) (actual time=0.196..0.761 rows=28 loops=1)
         Index Cond: (friend_id = 1)
         Buffers: shared hit=32
   ->  Materialize  (cost=0.57..8.59 rows=1 width=620) (actual time=0.002..0.002 rows=1 loops=28)
         Buffers: shared hit=5
         ->  Index Scan using total on i (cost=0.57..8.59 rows=1 width=620) (actual time=0.047..0.048 rows=1 loops=1)
               Index Cond: (user_id = 1)
               Buffers: shared hit=5
 Planning:
   Buffers: shared hit=3
 Planning Time: 0.644 ms
 Execution Time: 1.010 ms
(15 rows)

При этом, если ввести команду:
set enable_bitmapscan = off;
Первый запрос имеет адекватный cost и execution time. Как при select запросе указать нужный план, или как мне исправить данную проблему?
Что я уже пробовал:

CLUSTER index ON my_table;
REINDEX my_index;
DROP INDEX/CREATE INDEX
ANALYZE/VACUUM ANALYZE

+менял некоторые настройки postgresql.conf, ничего не дало результат. Версия postgresql: 14

Answer 1

[Melkij]

Я выполняю 2 одинаковых запроса

"WHERE friends_info.user_id = 1" vs "WHERE friends_info.friend_id= 1"

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

Bitmap Index Scan on ix_friends_user_id (cost=0.00..61.56 rows=5465 width=0) (actual time=0.742..0.743 rows=88 loops=1)

Суть ошибки выбора плана. Какое распределение данных в таблице? Каков размер самой таблицы? Вероятно несколько пользователей занимают значительную часть таблицы и это сбивает оценку селективности.
Простое чуть приподнять SET STATISTICS по полю, собрать новый analyze и посмотреть на оценку числа строк.

PS: индекс ix_friends_user_id должен быть удалён как бесполезный при наличии friends_info_user_id_friend_id_key

Comments

[che_aa]

индекс ix_friends_user_id должен быть удалён как бесполезный при наличии friends_info_user_id_friend_id_key

По моему опыту, без этих индексов цена select`а взлетает в небо

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

С точки зрения индексов, запросы полностью одинаковые, когда я добавлял индексы, на оба этих запроса был одинаковый план и идентичный cost, со временем таблица в этом плане деградировала.
В таблице примерно равное распределение данных, есть лимит на 5.000 друзей, но у подавляющего большинства не более 300, всего 160 млн. строк.
Попробовал поменять SET STATISTICS на более высокие значения, и на более низкие, это не помогло

[Melkij]

По моему опыту, без этих индексов цена select`а взлетает в небо

не множественное, а единственное число. Один индекс нужен, второй бесполезен и вреден.

как менялась оценка и при каких конкретно stats target'ах?
покажите select * from pg_stats where tablename = 'friends_info' and attname = 'user_id' \gx

[Мирон]

Melkij,
--
Вероятно несколько пользователей занимают значительную часть таблицы и это сбивает оценку селективности.
--
В планах, представленных пользователем, есть исчерпывающая информация по количеству выбранных линий. Их ровно 88 в плане, который выглядит не оптимальным.
88 линий трудно предположить, как нечто похожее на то, что Вы предположили "Вероятно несколько пользователей занимают значительную часть таблицы и это сбивает оценку селективности."
Наверное стоит читать план запроса предложенный пользователем несколько более внимательно.
В моем ответе есть скрипт смоделировать данные и изучить поведение индексов, если у Вас есть желание.
--- @che_aa
По моему опыту, без этих индексов цена select`а взлетает в небо
---
Теоретически можно иметь много различных мнений и аргументов, в данном случае Ваш практический опыт такой же, как и мой.
И потом индексы не равны
Первый вообще-то не индекс, а unique constraint. Тот факт, что он поддерживается индексом, это техническая деталь, поскольку его забота оградить родство от повторения домена user_id + friend_id.
Учитывая тот факт, что данный unique constraint не поддерживает оптимальный план и у Вас и у меня, я склоняюсь к мнению, что насколько такая конструкция поддерживает оптимальность выборки требует отдельного исследования. Хотя, ради эксперимента его конечно стоит уничтожить и создать заново. Чтобы ушли все сомнения.
Кроме того индекс
"ix_friends_user_id" btree (user_id)
не несет в себе поле "friend_id", и для тех запросов, где выборка не интересуется полем "friend_id" оптимизатор запросов предпочтет выборку по индексу наиболее соответствующему запросу.
И, поскольку, как заметил предыдущий комментатор, данные могут быть распределены между пользователями не одинаково, индекс с ключом user_id имеет право на жизнь. Особенно, если есть foreign_key, который на него опирается, допустим, из таблицы "user_info".

Answer 2

[Мирон]

Здравствуйте Уважаемый che_aa,

Вот SQL, который указывает, что кроме UNIQUE CONSTRAINT необходимо создать ещё и UNIQUE INDEX на тех же полях. Без UNIQUE INDEX план выполнения запроса действительно, не оптимален.

Я не уверен в причине этого поведения, вот цитата из документации продукта:

Adding a unique constraint will automatically create a unique B-tree index on the column or group of columns listed in the constraint. A uniqueness restriction covering only some rows cannot be written as a unique constraint, but it is possible to enforce such a restriction by creating a unique partial index.

В дополнение, в определение индекса добавлено поле unix_time_check в части INCLUDE.

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

-- DROP TABLE IF EXISTS public.friends_info;

CREATE TABLE IF NOT EXISTS public.friends_info (
  user_id         bigint
, friend_id       bigint
, unix_time_check bigint
);

ALTER TABLE IF EXISTS public.friends_info
ADD CONSTRAINT friends_info_user_id_friend_id_key UNIQUE (user_id, friend_id);
CREATE INDEX IF NOT EXISTS ix_friends_friend_id ON public.friends_info (friend_id);
CREATE INDEX IF NOT EXISTS ix_friends_user_id ON public.friends_info (user_id);

WITH EncodedData AS (
SELECT gs.rownum
     , gen_random_bytes(4) AS RandBytes
FROM generate_series(1,1000000) gs (rownum)
    WHERE NOT EXISTS (
       SELECT 1
       FROM public.friends_info
       LIMIT 1
  )
), DecodedData AS (
    SELECT rownum
	      ,(get_byte(RandBytes, 0)::bigint + (get_byte(RandBytes, 1)::bigint << 8) + (get_byte(RandBytes, 2)::bigint << 16) + (get_byte(RandBytes, 3)::bigint << 24))::bigint
	            AS RandBigInt
	FROM EncodedData
), PreparedData AS (
 SELECT rownum AS user_id
      , (RandBigInt % 1000000) + 1 AS friend_id
      , RandBigInt AS unix_time_check
 FROM DecodedData
)
INSERT INTO public.friends_info (
  user_id         
, friend_id       
, unix_time_check 
) SELECT 
  user_id         
, friend_id       
, unix_time_check 
FROM PreparedData;

-- EXPLAIN (ANALYZE,BUFFERS)
SELECT * 
FROM friends_info 
LEFT JOIN friends_info i ON friends_info.friend_id = i.user_id 
WHERE friends_info.user_id = 1;

CREATE UNIQUE INDEX IF NOT EXISTS friends_info_user_id_friend_id_key2
ON public.friends_info (user_id, friend_id) INCLUDE (unix_time_check);

-- EXPLAIN (ANALYZE,BUFFERS)
SELECT * 
FROM friends_info 
LEFT JOIN friends_info i ON friends_info.friend_id = i.user_id 
WHERE friends_info.user_id = 1;

-- EXPLAIN (ANALYZE,BUFFERS)
SELECT *
FROM friends_info 
LEFT JOIN friends_info i
ON friends_info.friend_id = i.user_id 
WHERE friends_info.friend_id=592737;

Вообще, есть интересные возможности решить запрос такого типа используя следующее GraphDB расширение СУБД Postgres. Это было бы неплохим испытанием на прочность. Если Вы интересуетесь, оставайтесь на связи.

Comments

[Melkij]

Читайте внимательнее. Документация ничего не сказала о том, что вам нужно создавать отдельный уникальный индекс.

unique constraint как требуемая по SQL spec сущность реализована как уникальный btree в postgresql. Не может быть unique constraint без уникального индекса. Создавать же отдельный индекс идентичный существующему unique constraint не только малополезное занятие, но и вредное.

В дополнение, в определение индекса добавлено поле unix_time_check в части INCLUDE.

Зачем?

[Мирон]

Melkij,
прежде, чем задавать вопросы, попытайтесь прочитать что написано внимательнее.
Задача не высказать мнение, а найти способ выполнить запрос с планом имеющим оптимальные параметры.
Мой ответ выполняет это требование пользователя.
Возможно у Вас есть лучшее решение, но я его в Вашем ответе не нашел.
Попытайтесь собрать свои комментарии вокруг того, что запросил пользователь.
Если у Вас есть вопрос, который Вы хотите прояснить, в частности, почему необходимо делать то или иное действие, будьте добры, откройте отдельный вопрос, и если я найду, что у меня есть знания, чтобы на него ответить, с удовольствием Вам помогу.
Но это должен быть отдельный вопрос.
---
Отдельной строкой,
в принципе, вопрос который Вы задали достаточно прост, и на него приятно ответить, чтобы дополнить оригинальный вопрос пользователя. Но таких дополнительных вопросов в деле оптимизации запроса в СУБД может быть очень - очень много.
По этой причине, убедительная просьба, для дополнительных вопросов открывать свой, отдельный вопрос для ответа, который позволит сфокусироваться на том элементе оптимизации запроса, который Вас интересует.
В частности ( если я правильно понял Ваше направление мысли )
Вопрос № 1 почему необходимо создать индекс, когда есть UNIQUE CONSTRAINT на тех же полях.
Для того, чтобы ответить на Ваш вопрос наверное придется смотреть код СУБД.
---
Вопрос № 2 почему в индексы необходимо включать поля в части INCLUDE
Это общий вопрос, по которому будут даны адреса соответствующей документации и небольшой текст с запросами языка SQL с примерами и пояснениями
---
Проблема в том, что каждый из этих вопросов, если Вы посмотрите документацию, имеет развернутые пояснения с множеством документов, и включать эти общие вопросы по СУБД и оптимизации запросов в конкретный запрос пользователя не поможет пользователю улучшить запрос, а отвечающему найти ответ для пользователя.

[Мирон]

Скрипт для GraphDB помог выявить в Age свои проблемы с оптимальностью запроса на таблице имеющей 1 миллион записей для user_id+friend_id.
Ранее я работал с базой, где количество строк ограничивалось 200 тысяч, и там все выполнялось намного быстрее.
С Вашего разрешения поделюсь скриптом с инженерами и вернусь, когда запросы в vertvex + edge имеющие 1 миллион записей и более выполняются побыстрее :)
Я имею ввиду довольно быстрый поиск решения, который либо выявит ошибку в существующей поддержке индексов, либо есть наработки по альтернативному индексированию полей. Так или иначе, 1 неделя выглядит как срок.
Вот сам скрипт:

-- CREATE EXTENSION IF NOT EXISTS age;
LOAD 'age';
SET search_path = ag_catalog, public, "$user";

do
$RUN$
DECLARE
    ag_map_var    agtype;
    ag_output_var agtype;
BEGIN
    LOAD 'age';
    SET search_path = ag_catalog, public, "$user";

    IF NOT (ag_catalog.graph_exists('friends_graph')) THEN
        PERFORM create_graph('friends_graph');
    END IF;

    IF NOT (ag_catalog.vertex_exists('friends_graph', 'user')) THEN
        PERFORM create_vlabel('friends_graph', 'user');
    END IF;

	CREATE INDEX IF NOT EXISTS ix_friends_graph_user ON "friends_graph"."user"
        (ag_catalog.agtype_access_operator(properties, '"user_id"'::agtype));

    IF NOT (ag_catalog.edge_exists('friends_graph', 'friend_of')) THEN
        PERFORM create_elabel('friends_graph', 'friend_of');
    END IF;

    RAISE NOTICE 'Starting creating vertex users %', clock_timestamp();

    FOR ag_map_var
    IN  SELECT ag_catalog.datum_to_agtype_map(fi.*)
	    FROM public.friends_info fi
    LOOP
        SELECT INTO ag_output_var
              *
        FROM cypher('friends_graph', $$
           CREATE (u:user {
        	      user_id: $user_id
            	, unix_time_check: $unix_time_check
           })
           RETURN u
        $$, ag_map_var) AS (e agtype);

    END LOOP;

    RAISE NOTICE 'Finished creating vertex users %', clock_timestamp();
	
END;
$RUN$;


do
$RUN$
DECLARE
    ag_map_var    agtype;
    ag_output_var agtype;

	progress_ind_var bigint = 0;
BEGIN
    LOAD 'age';
    SET search_path = ag_catalog, public, "$user";

    SELECT INTO ag_output_var
          *
    FROM cypher('friends_graph', $$
       MATCH (f:user), (u:user)
               WHERE f.user_id = $friend_id
			   AND u.user_id = $user_id
			   AND NOT EXISTS ((f)<-[:friend_of]-(u))
                   CREATE (f)<-[e:friend_of]-(u)
           RETURN e
        $$, ag_map_var) AS (e agtype);

		IF (0 = (progress_ind_var % 1000)) THEN
		    RAISE NOTICE 'Created % users, %', progress_ind_var, clock_timestamp();
		END IF;
		
        progress_ind_var := (progress_ind_var + 1);

    END LOOP;
END;
$RUN$;

SELECT *
FROM cypher('friends_graph', $$
   MATCH (u:user)
   RETURN u
$$) AS (u agtype);

его самой интересной частью являются запросы между $$, это язык Cypher, GraphDB диалект.
Он довольно прост и элегантен. Что - то здоровское подобрать, если есть время.

[che_aa]

Можете подсказать, есть ли у postgresql встроенный метод для изменения ожидаемого количества rows? Так как он считает этот параметр как:
Общее кол-во строк/кол-во уникальный строк
И в моем случае это является неверным

[Мирон]

che_aa,
это как раз обязанность оптимизатора запрос.
Количество строк зависит от конкретного сочетания доменов и уникальности данных и никто не может сказать заранее, что даже тот же самый запрос выдаст заранее известное количество строк, поскольку в СУБД принято считать, опираясь на худший ( для планировщика ) из возможных сценариев. И худший сценарий, это изменение количества строк в момент запроса. Очередность выполнения запроса внутри этой "машины" СУБД обычно следующая.
1 приходит текст запроса
2 рекурсивная функция дробит запрос на выполнимые блоки
3 оптимизатор получает запрос в виде такого вот результата рекурсивной функции, которые выглядят, как древо с хорошо проработанными деталями, которые должны быть достаточны для качественной оценки следующих шагов и выбирает как утилиты физического доступа к хранилищу данных должны действовать, как обобщить данные, использовать один потом или несколько и так далее.
3.а этот шаг опирается на некоторый запас метаданных собранных и хранимых СУБД, который называется "статистики".
4 каждое физическое действие сопровождается создание "слепка данных"
--- в этом месте можно было бы вбить клинышек, и посчитать количество строк, но оптимизатор уже отработал. Последующие шаги ведут к помещению данных в память, где СУБД выполняет различные действия, и по мере того, как тот или иной блок задания выполнен СУБД записывает сколько строк собрано.
----
Я могу быть не прав в тонких деталях, но в общем это достаточно близко к тому, что СУБД, как машина, делает для выполнения запроса. Из чего должно быть понятно, что мы, пользователи или администраторы, не имеем доступа, чтобы сказать оптимизатору запроса сколько строк он получит и посчитает в шаге 4.
Что мы можем дать оптимизатору запроса это
а. хорошо "подбитые" статистики данных, из которых он может точнее оценить как правильно построить шаги в 4.
б. не так давно ( года 2 назад ) на рынке был продукт sr_plan, но он не поддерживается, во всяком случае публично, последние 2 года. С его помощью можно было предложить оптимизатору отказаться от 3, и предложить ему готовый план, который Вы считаете правильным, по сути принудить оптимизатор воспользоваться планом, который Вы считаете правильным.
В совокупности sr_plan + aop + (ещё одна фишка) сейчас рекламируется Green Plum v7, как компетентное решение возможных проблем с оптимизатором запросов, совместимый с Postgres. Если Вас интересует не конкретный вопрос, а общий подход.
-----
Оценка количества строк это функция блока СУБД, который называется ( по - английски ) "cardinality estimator". Как раз в последние 10 лет многие СУБД озаботились их обновлением, возможно есть смысл погуглить на интернете такое обновление / альтернативное решение для Postgres. Опять же, если Вы ищете общий подход к похожему классу задач.
----
В конкретном случае мне кажется необходимо сделать шаг назад и решить, что делать.
В словах Melkij есть смысл. Ради эксперимента можно попробовать
1 убрать индекс с user_id и оставить только unique constraint.
2 удалить и заново создать unique constraint
и посмотреть, если это решило проблему с не оптимальным запросом. Теоретически это, как "должно работать". Но у меня так на моем компьютере работает нет. Давайте так, если "теоретически правильный вариант" у Вас работает, все здорово, если нет, то вернемся и продолжим искать обходной путь.
Если Вы прочитали мое решение, которое на моем компьютере работает "да", то необходимо добавить unique index. Он хорошо работает и сам себя поддерживает. В принципе, это и есть то, что решает проблему между 3 и 3.а выше ( и то, что Вы спросили, подладить верные статистики ).
И хотя он выглядит как нахлобучка, в практике, если "нахлобучка" решает реальную проблему ей рады и это не считается чем - то чрезмерным.
----
Вы не спросили здесь в комментарии, но этот вопрос есть в оригинальном запросе, это строка с
set enable_bitmapscan = off;
Для сужения области воздействия этой команды необходимо использовать опцию "local"
set local enable_bitmapscan = off;
и тогда эта опция оказывает действие только на сессию, в которой выполняется запрос. Но если выбирать между индексом нахлобучкой и SET опцией, я бы предпочел индекс.
----
Почему я не предлагаю заменить unique constraint на unique index.
При всей схожести, это разные вещи.
Constraint, это инструмент имеющий область воздействия базы, эти объекты заносятся в каталоги имеющие область видимости базы данных и их внесение и удаление проходит под другим уровнем внутри машины СУБД. Индексы же, это инструмент работы с одним, отдельно взятым родством.

должен поправить себя.
В Postgres индексы так же имеют область видимости всей базы данных. Поэтому с индекс с уникальным именем может быть только один во всей базе данных.
Что возвращает меня к моему оригинальному скрипту :)
Видимо в процессе эксперимента с данными, которые не вошли в скрипт я убрал unique constraint и внес индекс. После чего план запроса стал оптимальным.
Твк, как скрипт приведен, он выдаст сообщение
---
NOTICE: relation "friends_info_user_id_friend_id_key" already exists, skipping
CREATE INDEX
---
Видно так искал проблему, что не уследил за каждым своим шагом и сделал ошибку.

По этой причине есть некоторые выражения, используемые в запросах, на разрешение конфликтов на дубликаты, где используются имя constraint, в случае, если хотят использовать индекс ( надеясь, что оптимизатор запросов его вовремя идентифицирует, иначе это может стать очень - очень длинной операцией, которая принесет проблемы с функционалом ), то необходимо создать выражение с списком колонок. То есть удаление unique constraint и его замена на уникальный индекс потребует изучить базу и, возможно, изменить код некоторых процедур или скриптов. Поскольку прибавление индекса не смертельно, я бы добавил индекс, решив очевидную проблему, а затем продолжил в итеративном ключе его улучшение.
Это план, на случай, если "теоретический подход" не работает.
---
Ну и наконец, есть вариант с исследованием причин, по которым индекс, поддерживающий unique constraint ведет себя таким вот образом.
Ваш наводящий вопрос подсказывает, что, возможно, этот индекс живет с регулировками статистик требующими близкого ознакомления. Стоит приглядеться к нему поближе. Это наиболее вероятный сценарий, посмотрю, если что - то можно найти пользуясь каталогом базы и утилитами.
Но не исключено, что надо выполнить запрос, поставив сам Прогресс СУБД под построчный отладчик :). В этом случае должен признать, учитывая, что у Вас на руках есть решение с индексом нахлобучкой ( 15 минут ), и таким вот глубоким изучением проблемы в несколько часов на моей стороне, время взывать к совести :))) урр-мяу.
Удачи.

[Мирон]

che_aa,
Прошло почти две недели.
За это время я нашел следующмй продукт:
Расширение для Postgres, позволяющий использовать хинты в запросах базы данных.
Он настолько популярен и востребован, что поддерживается в том числе облачными сервисами, например, Microsoft Azure
В запросе, который рассматривается выше наверное подходящий хинт, или несколько будет выглядеть следующим образом:
/*+Set(max_parallel_workers_per_gather 0)*/
Дело в том, что запрос, который Вы попросили поправить, из - за сбоя с статистиками срывается в параллельный план. Такие вещи встречаются скорее часто и не только у Postgres, и именно в таких вот случаях использование хинт в запросе считается общепринятым и нормальным подходом. То есть Вы в данном случае просто говорите СУБД "не используйте многопоточный план, потому, что я знаю, что индексы и данные подходят лучше для однопоточного". Как правило с таким вот нежным шлепком СУБД отрабатывают оптимальный план.
Это настолько просто, что я бы попробовал.
Для подтверждения что хинт действительный и работает я оставил следующий вопрос разработчикам расширения.
Итак, как должен выглядеть запрос, чтобы он работал правильно ( если хинт отработает так, как задумано )

/*+Set(max_parallel_workers_per_gather 0)*/
SELECT *
FROM friends_info 
LEFT JOIN friends_info i 
          ON friends_info.friend_id = i.user_id 
WHERE friends_info.user_id = 1;