set enable_bitmapscan = off;set local enable_bitmapscan = off;
должен поправить себя.
В Postgres индексы так же имеют область видимости всей базы данных. Поэтому с индекс с уникальным именем может быть только один во всей базе данных.
Что возвращает меня к моему оригинальному скрипту :)
Видимо в процессе эксперимента с данными, которые не вошли в скрипт я убрал unique constraint и внес индекс. После чего план запроса стал оптимальным.
Твк, как скрипт приведен, он выдаст сообщение
---
NOTICE: relation "friends_info_user_id_friend_id_key" already exists, skipping
CREATE INDEX
---
Видно так искал проблему, что не уследил за каждым своим шагом и сделал ошибку.
-- 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);Test<T> and extend template with T type for the property data type.Хранение данных каталога с быстрым доступомSolr это индекс текста для поиска NLP или похожего, так же на Lucene.
И что там на счёт Task.Run?
Вполне возможно, что у тебя одновременно отрабатывает и сохранение и выгрузка.
Entity Framework Cache Busting
2016-02-19
The DbContext in Entity Framework 6 automatically caches data that it retrieves from your database. This is useful, but sometimes data changes outside your context (perhaps by another user) and you end up with stale data.
Прошло почти две недели.
За это время я нашел следующмй продукт:
Расширение для Postgres, позволяющий использовать хинты в запросах базы данных.
Он настолько популярен и востребован, что поддерживается в том числе облачными сервисами, например, Microsoft Azure
В запросе, который рассматривается выше наверное подходящий хинт, или несколько будет выглядеть следующим образом:
/*+Set(max_parallel_workers_per_gather 0)*/
Дело в том, что запрос, который Вы попросили поправить, из - за сбоя с статистиками срывается в параллельный план. Такие вещи встречаются скорее часто и не только у Postgres, и именно в таких вот случаях использование хинт в запросе считается общепринятым и нормальным подходом. То есть Вы в данном случае просто говорите СУБД "не используйте многопоточный план, потому, что я знаю, что индексы и данные подходят лучше для однопоточного". Как правило с таким вот нежным шлепком СУБД отрабатывают оптимальный план.
Это настолько просто, что я бы попробовал.
Для подтверждения что хинт действительный и работает я оставил следующий вопрос разработчикам расширения.
Итак, как должен выглядеть запрос, чтобы он работал правильно ( если хинт отработает так, как задумано )