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

Paul Chabinsky1. получить всех предков определенного элемента.
Рекурсии не нужнызначит помню правильно :)


Да, кстати:
если я правильно понимаю, это довольно неприятные условия для индекса (left,right) ? Видимо по лефт идет поиск по индексу, а по райт - уже фильтр?

nostromoКажется, если таблица в памяти мало места занимает, то на диске и подавно :)смысел не в месте в памяти, а в соотношениии цен дисковых операций к операциям в памяти. ( т.е. чисто физические 3-4 порядка -прим. для математиков именно этим кстати кажеца объяснялося модное стартование tempdb в память для мс-скуль 6.5 ) А поскольку все данные этой таблицы - исчисляемые, (изьыточные) - то и нет необходимости хранить их на диске (достаточно строить, но быстро и один раз, после старта)

да, а по поводу хидеров - это кажеца повод хранить исчисляемую (избыточную, но необходимую для SQL выборок) иерархию в индексированных тестовых полях в виде .1.123.78987... - кол-во шапок на иерархию узла поджимаеца (даже если табличка иерархий будет отдельной от соб-сно дерева), правда апдейты пойдут с расщеплением поля, но, похоже, не сложным. (И еще - не потребуется ли обращенного индекса - т.е. (функционального?) индекса на обращенную строку?)
Что вы об этом думаете?

nostromo Например, перевод из текста в число операция не самая быстрая ну в случае хранения иерархий в поле (hierarchy text;) запросы на вхождение будут иметь (скажем) вид
WHERE c.hierarchy LIKE t.hierarchy||'.*'
т.ч. преобразование типов тут не нужно. (оно потребуется только при заполнении hierarchy триггером - из числа в текст)

nostromo т.к. память экономится только для маленьких значений (которых меньшинство): 4-х байтовое целое занимает до 10 байтов в десятичной десятичной и до 8 в шестнадцатеричной. речь шла о экономии на шапках записей - но кажется вы о том, что потери из-за преобразования в строку их съедят?

nostromo 4321(И еще - не потребуется ли ... индекса на обращенную строку?)
Это не понял, поясните.мои извинения, - это ложный перенос идеи о 2-х индексах (pid,id)|(id,pid) (что удобно для поиска как предков так и потомков) на случай текстовой иерархии. Кажется индекс на обращенную строку не пригодится - предки ищутся так же как и потомки только таблицы меняются в LIKE местами.



_______
ЗЗЫ:
nostromoЕсли мыслить масштабно, то, кажется, идеальный вариант для любого алгоритма, оптимизирующего работу с некторой структурой -- это соответствующий встроенный в систему индекс плюс оптимизатор, умеющий его эффективно использовать. Может, пора связываться с разработчиками или писать свое расширение? :)а я вот не думаю, что тут пора "мыслить масштабно". Ибо...
Ибо обнаружил, что идея спотыкается на том, что при апдейте (пересадке веток) приходится прибегать к использованию конструкций вида
DELETE ... WHERE t.field IN(SELECT f FROM ....)
(или (t.f1,t.f2) IN( SELECT f1,f2 FROM....)
, а они даже для случая отсутствия зависимости сабселекта от полей внешних (к сабселекту) считаются неоптимально - а именно сабселект считается для каждой записи (я даже пытался подоткнуть туда STABLE ф-ю -думая обмануть природу - ан. фих). Т.ч. экономия метода частична - вставка веток - дело практически "бесплатное" (недорогое), но вот пересадка (даже терминалов, если не выделять их пересадку в отдельную ветку триггерного алгоритма) напрягает.

я конечно нашел, что можно обмануть эту проблему (почти на порядок - полтора на ~100 000 записях в иерархичке) составлением стрингов для IN(,,,,), но это, мне кажеца, "не дело" - неужто оптимизатору так трудно выяснить отсутствие зависимости сабселекта от полей выбираемой в селекте записи? Вот уж что действительно давно пора бы было от"оптимизировать" разработчикам...

LeXa NalBat 4321DELETE ... WHERE t.field IN(SELECT f FROM ....)Можно заменить на exists ( select 1 from ... where f=t.field ). Или приджоинить: http://www.postgresql.org/docs/8.0/static/sql-delete.html#AEN41779Спасибо, посмотрю!
( Я как раз и хотел поругаца на отсутствие "ДИЛЕТА ... ФРОМ ДЖОНА" (як скажем в неких настольных вструментах типа аксеса). Тут, насколько я понял, омиттед фром в полной красе. Вот только дилет форм аутер джон так кажеца не реализуеца.)

Что касаеца exists - пробовал в первую голову, получил времена на полпорядка _хуже_, чем при 2-х id IN(Select ...) AND pid IN(Select ...). Пока (из опробованного) наискорейшее - сшивать строку IN(,,,,,) и выполнять EXECUTE (при малом количесве подчиненных срабатывает раз в 10 -15 быстрее чем с IN(SELECT ...), но не совсем понятно, что будет при очень больших строках (есть ведь наверное и ограничения на длину SQL инструкции? Пока проверял - при перемещении веток с ~280 потомками по иерархии работает).
Правда появилась идея (не сшивать строку) а напрямую делетить записи в plpgsql-ой ХП в цикле (в аксессе бы подобное в VBA делать не стал - заведомо плохо, но в plpgsql имеет смысл оттестировать для пробы).

, сорри, не заметил: also it cannot handle self-joins. т.ч. джойн по омиттед фром нервенно курит у сторонке (мля)

4321, сорри, не заметил: also it cannot handle self-joins. т.ч. джойн по омиттед фром нервенно курит у сторонке (мля)Фихвам! Абманём за счет вью! (голь на видумки хитра)

2 LeXa NalBat
к проблеме DELETE FROM ... WHERE IN(... ) на моих данных:

к сожалению нагрузка на сервер непостоянна. Т.ч. тестовые результаты различаются иногда на порядки по временам (на одних и тех же данных). Поэтому числа не привожу. Но примерно такое резюме (при подмене функций в триггере обновления предка узла дерева):

1.EXECUTE (... IN (\' ||с_подстановкой_наборов||\' ) ~ на порядок лучше изначального дилета.

2. цикл DELETE внутри лупа - близко по скорости к дилету по 1. (на ~ 280*3 записей в лупе). (очень может быть, что скорости дилетов по пп. 1. и 2. разнятся сильнее - в триггере есть еще и инсерты, дающие примерно такой же вклад, но радует хотя бы то, что не надо думать о предельной длине SQL строки)

3. дилет с "ommited from" джойном в WHERE с 2 видами (той же таблицы) - раза в 2-3 похуже 1 и 2

4. Очень хотелося неявно заджойнится на SETOF ф-ю. Но, кажется этого нельзя. Т.е. нельзя ни заполнить сетоф переменную в plpgsql, ни написать
функция($1).поле в WHERE. Можно видимо посмотреть в сторону времянки. Но времянки - это к сожалению не фонтан (дисковые операции).

ЗЫ: надо бы потестить чистые дилеты на модельных данных, на незагруженном сервере. неушто придеца дома

LeXa NalBat 43213. дилет с "ommited from" джойном в WHERE с 2 видами (той же таблицы) - раза в 2-3 похуже 1 и 2киньте пожалуйста explain как говорилося выше:(при подмене функций в триггере обновления предка узла дерева)где для случая джойна подставлялась:
для предка 74 имеется 3 прямых и 280 иерархических потомков