Гаджимурадов РустамКак ты будешь больше одного атрибута мапить?
Не говоря уже о параллельном доступе.Больше 1 атрибута на ключ ? А что, сейчас в rdb$set_context'e это уже можно сделать ? ;-)
Что касается паралл. доступа, то - да, погорячился я там. Синхр-зация нужна.

Гаджимурадов Рустам> да и опять всё станет похоже на мир fixed-таблиц.

А какие к нему есть претензии, кроме производительности
(и мусора, что тоже частный случай производительности)?А это и есть претензия. Делать ПЯТЬ фетчей для выборки константы из rdb$database - в наш стремительный век не комильфо как бэ...

Гаджимурадов РустамНе говоря уже о том, что задача не ахти какая насущная и
полезная с прикладной т.з.я всего лишь озвучил то, что у нас тут "вдруг" захотели местные пинкертоны-СБшники и радетели за чистоту рядов.

dimitrCделать можно почти что угодно, вот только нафига...Минимизация обращений к базе. Это - единственное "фиг а ", которое я подразумевал в стартовом посте.
Я просто хорошо помню, что когда мы заменили обращения к справочнику констант приложения на rdb$get-context'ы, то произв-сть выросла. Некоторые отчёты стали делаться на 15-25% быстрее, а были и те, что в полтора раза ускорились.
Разумеется, однократное чтение из этого справочника каждой константы всё равно было, и каждый коннект однократно лез за нужной ему константой в эту многострадальную таблицу.

Это, кстати, еще один пример: константы приложения. ID'шники, первичные ключи каких-то родительских записей (справочников) - они ведь вообще никогда меняются. Первый же коннект, пролезший к базе с начала работы, взял да и составит Map-структуру, доступную далее для ВСЕХ последующих аттачей.

Что, опять не актуально ? ;-)

Dimitry Sibiryakovdimitrон желал неблокирующую грязную запись
Мой ХШ указывает скорее на грязное чтение, просто он как всегда выражается не совсем точно.нет, я действительно там сморозил, т.к. имел в виду именно dirty write :-)

Dimitry Sibiryakovdimitrон желал обходить ее в порядке возрастания ключейЯ уверен, что его можно убедить отказаться от этого требования.Да, наверное так. Обход в порядке возрастания строковых ключей - это было надуманным требованием. Можно и без него.

Гаджимурадов РустамТаблоид> Больше 1 атрибута на ключ ? А что, сейчас в rdb$set_context'e это уже можно сделать ? ;-)

Ты когда-нибудь научишься читать, что тебе пишут?
Я уже раза два сказал, что твои "таблицы не таблицы"
никакого отношения к контекстным переменным не
имеют, вообще никакого.я внимательно читаю все посты, в т.ч. твои.
То, что ты "уже два раза сказал" - еще не значит, что ты сказал Истину в последней инстанции :-)
Объясни, чем именно нынешняя реализация контекстных переменных принципиально отличается от того, что я запрашивал. Я не понимаю голословных восклицаний.


Гаджимурадов Рустам> А это и есть претензия.

Значит нужно ставить соотв. задачу/хотелку по их
ускорению (опциональному, в редких случаях и т.п.),
а не созданию совершенно новой фичи.В где её ставить, в трекере ? Я уже наставился там. Improvement-реквесты от моего авторства там обычно уходят в клозет ('closed' :)).
Индексный доступ в ФБ *не* может быть реализован иначе, как "сначала лезем в индекс, а затем только в таблицу за данными". И часть ключа из индекса, если запросу нужна именно она, *не* может быть задействована сразу: всё равно надо проверять, имеет ли право текущая Тх видеть это. А значит, снова лезем в таблицу.
Оттого и рождаются идеи о новых структурах, раз со старыми ничего нельзя поделать.

Гаджимурадов Рустам> Делать ПЯТЬ фетчей для выборки константы из rdb$database
> - в наш стремительный век не комильфо как бэ...

Это уже совершенно третья фича и на её обсуждение
уже дал ссылку Денис.Это не фича (в смысле, это не запрашиваемая фича). Это констатация факта, который ЕСТЬ.


Гаджимурадов Рустам> я всего лишь озвучил то, что у нас тут "вдруг" захотели
> местные пинкертоны-СБшники и радетели за чистоту рядов.

Тогда озвучь то, что они захотели, а не свой вариант реализации,
тем более, что к чистоте рядов это никак не относится, совсем.Я и озвучил именно ИХ запросы, а не наш вариант реализации. "Ты когда-нибудь научишься читать, что тебе пишут?" (С)

Гаджимурадов РустамТы в этом топике озвучил 3-4 различных фичи, так
что не очень понятно, какую именно ты имеешь в виду.

1. Есть таблицы (fixed и gtt).Топик не про них. Совсем.
Гаджимурадов Рустам2. Есть текущие контекстные переменные.Да, но синтаксис их использования чересчур громоздкий. Я спросил про синтаксический сахар, но эхо ответило "данунах", так что этот вопрос закрыт.

Гаджимурадов Рустам3. Есть хотелка на добавление неймспейса GLOBAL для текущего функционала контекстных переменных.Это было добавлено в стартовом посте в виде "PS", и как раз по нему пошло основное обсуждение. От темы топика: "Хотелка к 3.х: вопрос(ы) по контекстным переменным" - не в сторону сильно ушло ?

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

Гаджимурадов Рустам4. Есть твоя хотелка "непонятно чего" (потом что на данный момент ничего подобного нет, кроме индексов) - некоей новой структуры, которая будет нетранзакционной и хранить только одну пару ключ-значение (или как?).Это не новый (4-й) пункт, а описание хотелки к реализации пункта № 3. Соб-сно, там ничего нового нет. Контекстные переменные на сегодня и так хранятся в map-структуре с парами "ключ - значение".

Гаджимурадов РустамПри этом накладываются (запрашиваются) непонятные (необоснованные) ограничения на механизм записи. Какие ? про грязную запись я выше уже сказал: каюсь, фигню там сморозил. Надо еще раз, ж ы рно-красными буквами что ле ?

Гаджимурадов Рустам5. Есть ещё старый разговор о том, что выборка констант (а-ля селект из rdb$database) слишком
медленна и предложение нового синтаксиса для избежания обращений к диску (ссылка Дениса).Ссылка-то Дениса, а топик тот - "мой" :-)
Не надо на него вообще переключаться, на разговор этот. По той ссылке много чего видно. По этой теме пока что всё остается точно так же, как и было 3-5-10 лет взад. Всплыло это всё от того, что было предложение затолкать такие переменные в обычную fixed-таблицу. Это профанация всего светлого замысла.

Гаджимурадов Рустам(обсуждение- трекер -реализация-тестирование)я уже намекал: затолкайте кто-нибудь в трекер этот improvement-request. На меня там аллергия у кое-кого, зарубят на корню :-)

Гаджимурадов Рустам> Индексный доступ в ФБ

Ты вроде как выше отказывался от индексов.
Да и не нужны они для твоей хотелки (№4).ты зачем вырвал кусок фразы, а ? ;-)
я про индексный доступ сказал не для того, чтобы прикручивать его к map-структуре, а потому, что он не может быть использован БЕЗ обращения к таблице. И след-но, никакого профита от хранение большого числа global-контекстов в fixed-таблице не получим. Будем лезть в индекс, затем в таблицу. Разумеется, для map'a индекс не нужен - всё сразу берется из этого самого map'a.

Гаджимурадов РустамСБ - это кто? Ибо в общепринятом смысле слова они ничего подобного не требуютЭто не те "дубы-колдуны", которые отставники наших славных мвд/фсб и прочая. Тут "внутренние аудиторы" появились. Вот о них и речь.
Может, они к СБ и не имеют отношения, но запросы у них - именно такие, "СБшные".

Симонов ДенисТы уже забыл о детерминистических функциях. Они позволят прочитать твою константу из таблицы один раз и дальше тупо возвращать результат из кэша. И насколько я понял для супера он будет общим. Это ведь решает твою проблему на 90%.Когда речь идёт о константах приложения - да, тут всё супер. А когда речь идет о меняющихся данных (как первый пример: "А кто щя в программе сидит и чё делает ?") - детерм. функции уже не катят.

Fr0sT-BrutalDarkMasterВ отрыве от контекстных переменных (мечтательно).

Эх, вот был-бы какой-нить отдельный процесс, на который можно было бы таймер/шедулер повесить....Где поставить свою подпись в поддержку?)
С одной стороны, вроде как не дело СУБД заниматься шедулингом, с другой - все равно ведь служба висит, почему бы не нагрузить ее периодическим выполнением разных полезных штук.Товарищи DarkMaster и Fr0sT-Brutal! за ваши оффтопы по башке от местных членов Политбюро получать буду *я*, понимаете ?.. ;-)
Вам никто не будет говорить, что "разводите топики на 100500 тем, читать это невозможно" и в итоге топик уйдёт в игнор.
Создайте отдельную тему для мечталок, плз.

Fr0sT-BrutalПо теме: возможно, все, что нужно, - это полностью доступная для чтения всеми коннектами GTT?Реализация НЕ должна быть таблицей. Никакой - ни fixed, ни GTT. Это должна быть структура в памяти, существующая только до тех пор, пока к базе есть коннекты.

Ivan_PisarevskyИли подходим "с заднего крыльца" к партиционированию... Часть таблиц на рамдрайве, на старте некий демон вливает туда данные и поехали.
???Залить константы приложения (коих может быть под 1000, а то и больше) в ram при первом коннекте - шикарнейшая вещь, но... причём тут "партиционирование" ?!

Симонов Дениссобираешься на каждого пользователя по переменной городить?Да, а что такого ? {user_id:some_info}: таких значений даже если 1000 будет - это в микроскоп не разглядеть.

Fr0sT-BrutalА на детали ее реализации - таблица, дерево, куст - программеру плевать, кмк.Это плевать до тех пор, пока у тебя не начнутся тормоза. Дальше ты полезешь оптимизировать свой код, PSQL & SQL. Затем ты его доведёшь "до абсолюта", а тормоза всё равно останутся. И вот тогда ты начнёшь думкать, а что же еще можно сделать. И раздел прикладной математики под названием "Структуры и алгоритмы" как-то сам по себе всплывет в сознании. Проверено.

Симонов ДенисДа и пространство контекстных переменных ограничено. Пусть даже его увеличат 100 раз всё равно мало станет с таким подходом.НЕ оффтоп. Я так и не понял, кстати, почему их число таки сильно ограничено. 1024 - нищебродство в век бесплатных гигабайтов.