Это называется "порог вхождения".
Если новички проекту Файрбёрд не нужны - то не нужно. Чем сложнее - тем лучше фильтрация. В клубе джентльменов должны быть только джентльмены.



там не совсем ES

там for ES ... into VARIABLE

и тут вопрос, сама Variable - она lazy или как ?
когда реально вытаскивается БЛОБ - сразу когда отработал шаг цикла, или когда (если) к этой переменной в самом деле обратились?

если чтение выполняется всегда - то в принципе можно ещё в сетевом поставить флажок, hint "это поле понадобится, высылай".
хотя "правильнее", наверное, было бы сделать, чтобы у переменной в SP была lazy-загрузка



Конкретно к даннмоу случаю - хватило бы просто отправлять длинну блоба. Если она нулевая - то конент блоба можно рассчитать на клиенте и не тянуть по сети, хоть бы даже и прямым перебором.
Другой вопрос - насколько это типовая ситуация, хранить в блобах данные нулевой длины???
Как вариант, можно в любой БД хранить специальный константный блоб нулевой длины с заранее известныйм ID, вот специально для таких БД. Много места он не займет.

В общем же случае - сделать какую-то оценку, статическую или динамическую на основе наблюдаемой задержки в round-trip. Блобы меньшей длины конвертируются в VARCHAR с эквивалентным CHARSET, большей - остаются блобами.
При этом, видимо, в протокол потребуется вводить понятие типа shadow column, который существует только как отображение основного столбца на другой тип данных. Если он null, то отображения нет и читай из основного. Если он not null - то клиент может рассчитать данные основного столбца на основании теневого столбца и основной столбец не дёргать, если захочет.

И какое именно предупреждение - тоже непонятно. "Идиотам вход воспрещён"?..

Какое - примерно понятно.

В описании BLOB'ов как типа указать, что чтение их выполняется множеством маленьких сетевых запросов, у каждого - свой раундтрип, и ограничивать скорость работы будет не пропускная способность сети, а латентность. И что хранить в блобах данные малого размера поэтому очень неэффективно как для места на диске, так и особенно для скорости работы по сети. А случай GF туда хорошим примером будет. "У друга моего друга однажды..."

И ссылки - на википедию в статьи по раундтрипам и латентности, а заодно на статью на Хабре про Видео mail.ru, как оно из США не работало, и пока разработчик лично в США не съездил и не убедился на месте - поправить не могли Там как раз хорошая обзорная статья по проблеме.

Разница именно в том, что простой select то ли будет читать поле с BLOBом, то ли нет

а PSQL FOR SELECT - вероятно читает всегда. Или не всегда? Или в SP переменная после SELECT может содержать только BLOB id, пока её реально не попытаются прочитать в коде?

Сколько - та самая оценка, когда ожидаемые минусу перевесят ожидаемые плюсы.
Где - в буфере под строку, в сетевых пакетах - в запись каждой строки.
Несколько блобов от одного не отличаются, оценка делается для "сферического блоба в вакууме". Конечно, идеально было бы иметь статистику для конкретного столбца в конкретной таблице, да ещё и с конкретным приложением-клиентом на конкретном рабочем месте - но это не реально. А вот roundtrip latency известна.
Клиентское приложение догадываться не будет, если использует старый API. Возможно, это вообще не нужно на уровень публичного API вытаскивать и можно целиком внутри wire protocol держать.
"Докачивать" блоб не нужно, он или полностью влез в shadow column, или нет.

Симонов Денис,

я ведь уже сказал, что такое делать надо на уровне сетевого протокола, и вываливать это наружу в виде SQLDA скорее всего нe нужно

обратная совместимость - а как это сейчас решается в wire протокол? скорее всего, версией протокола. Если не введи "локальную" расширяемость на тэгах.

ёёёёё,

SP не обязана обращаться к переменным.

Переменная может быть "просто так, на будущее"
Может быть, обращение к ней было, но потом его убрали/закомментировали.
Может быть, обращение к ней будет условным, в зависимости от других переменных.

Но - для этого у переменных в SP должен быть механизм lazy evaluation, а я очень сомневаюсь, что такой есть.
Но судя по реплике KDV - таки есть

ёёёёё,

SP не обязана обращаться к переменным.

Переменная может быть "просто так, на будущее"
Может быть, обращение к ней было, но потом его убрали/закомментировали.
Может быть, обращение к ней будет условным, в зависимости от других переменных.

Но - для этого у переменных в SP должен быть механизм lazy evaluation, а я очень сомневаюсь, что такой есть.
Но судя по реплике KDV - таки есть

Да, именно так. Как и с любой оптимизацией и любой эвристикой - есть риск "зря стараться".
То же "предсказание ветвлений" или "упреждающее чтение" в процессоре, уж какие там сложности наворачивают, детекторы того, детекторы всего, и всё равно иногда ошибаются.

Поэтому скорее всего бесполезно задавать константу (разве что только для отсечения совсем маргинальных случаев вида пустой строки или строки из 3 букв).
А только динамическое подстраивание под реально наблюдаемые в данном подключении условия сети.
И если в firebird.conf или database.conf, то тоже, видимо, подстройка может быть лишь не в абсолютных единицах, а в каких-то условных и вероятностных "больше склоняемся к такому варианту".



Ну я же уже написал! к запросу добавляются специальные невидимые, теневые столбцы "блоб из столбца M, если влезает в короткий nullable varchar(nn)"

через fbclient.dll API они недоступны, но при запросе к BLOB'ам клиентская библиотека туда поглядывает

jaybird и .net provider сами разберутся, если захотят обновлённый wire protocol реализовывать



Если предположить, что буфер под микроблобы - часть буфера строки, невидимый столбец, - то столько же, сколько живёт на клиенте буфер этой строки. Пока он жив - чтение BLOB'a выполняется из него. Уехала строка на радугу - всё, shortcut просрочен, читайте через обычные раунд-трипы.

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