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

Как быстрее всего апдейтнуть запись?

Winnipuhт.е. есть поле типа вектор, в енм нужно заменить часть вектора, скажем так: в векторе сидит путь в дерерве к узлу и мне надо перевесить узел под другой парент.

Как быстрее всего апдейтнуть запись?

ошибся, не вектор(!), а ARRAY

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

мне в общем случае надо менять:

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

пример:



2;"{1,2,3,7,8,9}"
3;"{1,2,3,4,10,11}"
1;"{1,2,3,4,5,6}"

заменить для id=1 и 3: заменить 1,2,3,4 на 1,2,3,7,8, т.е. перевесить поддерево к другому паренту

как такое сделать эфективно?

PostreSQL начинающий> в векторе сидит путь в дерерве к узлу и мне надо перевесить узел под другой парент

Сложно придумать что-то более тупое.

что именно по вашему мнению "тупое"?

PostreSQL начинающий> в векторе сидит путь в дерерве к узлу и мне надо перевесить узел под другой парент

Сложно придумать что-то более тупое.

где же вы, добрый, смелый и знающий человек?

PostreSQL начинающий> что именно по вашему мнению "тупое"?

"в векторе сидит путь в дерерве к узлу"

"не останавливайтесь же", что вы можете предложить?

PostreSQL начинающий> что вы можете предложить?

Вам - ничего. Для начала прочтите хоть что-нибудь по теме. Хотя бы из разряда "базы данных для dummies за 15 минут".

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

Вы на какой странице "базы данных для dummies за 15 минут"?

LeXa NalBat Winnipuhчто вы можете предложить?хранить дерево в виде (id, parent_id)

из-за специфики задачи я ушел от такого хранения, надо быстро искать, потому держу в записи путь

LeXa NalBat Winnipuh LeXa NalBatхранить дерево в виде (id, parent_id)из-за специфики задачи я ушел от такого хранения, надо быстро искать, потому держу в записи путьвыигрываете в одном, проигрываете в другом. может все-таки выбрать другой способ хранения... "надо быстро искать" - какие выборки нужны?

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

Если сделать "по теории", т.е. основная таблица узлов+подчиненная с путями, то получается
в мастер 50 млн записей, в подчиненной может быть до 20 уровней дерева, т.е. больше 250 млн.

LeXa NalBat Winnipuhдял поиска используется полнотекстовый поиск по основному полю и плюс уточняется расположение узла в дереве.
База предназанчена для поиска, но нужно перевешивать узлы, удалять, добавлять.

Если сделать "по теории", т.е. основная таблица узлов+подчиненная с путями, то получается
в мастер 50 млн записей, в подчиненной может быть до 20 уровней дерева, т.е. больше 250 млн.допустим такая структура

полнотекстовый индекс по полю search

id, parent_id, name, search, path
--
1, null, 'всё', null
2, 1, 'компьютеры', 'компьютер computer' -- по нелистовым узлам надо искать? у них может быть поле search не null?
3, 2, 'ноутбуки', 'ноутбук notebook'
4, 2, 'десктопы', 'десктоп desktop'
5, 1, 'телефоны', 'телефон, мобильник, сотовый, phone, mobile'

с какими ограничениями надо искать? только по полю search?

каков должен быть результат? показывать все найденные элементы и их предков в виде дерева?

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

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

select * from t where
string_vector @@ to_tsquery('default','polis & entire | antalya')
and
and '{"123722"}'::int[] <@ path_array::int[]

LeXa NalBat Winnipuhда предположим такой способ хранения дерева, нет доп. таблицы, где указаны все пути.

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

select * from t where
string_vector @@ to_tsquery('default','polis & entire | antalya')
and
and '{"123722"}'::int[] <@ path_array::int[]по какому плану, по вашему мнению, постгрес должен наиболее эффективно выполнить такой запрос?

поиск по полнотекстовому индексу (по всему дереву), и последующая фильтрация результатов по вхождению в поддерево?

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

LeXa NalBat Winnipuhоднозначно трудно сказать в каком случае оптимальнее, видимо так.
Наример, если юзер указывает узел близкий к корню, то под ним будет намного больше потомков, чем войдут в полнотектсовый критерийтогда создаете две plpgsql функции
bool tr_contains(parent_id int, id int) - является ли parent_id предком для id
setof int tr_subtree(parent_id int) - возвращает id всех потомков для данного parent_id

в зависимости от объема поддерева можете выбирать один из запросов
select * from ( select * from table where string_vector @@ to_tsquery('a') ) where tr_contains(123722,id) -- по полнотекстовому индексу
select * from ( select * from tr_subtree(123722) ) where string_vector @@ to_tsquery('a') -- без полнотекстового индекса

ок, буду пробовать

domanixГлянте на контриб модули
intarray и ltree
Может пригодится заявленная там функциональность?

спасибо, посмотрю.
Они не включены в 8.3 ?
Если руками добавлять, то наверное под виндоуз проблематично будет.
Мне надо, чтобы под линуксом и под вин работало...