АЛ
Я видел такую реализацию на хранении информации о прохождении ФЛК. Там много всяких проверок - у каждой проверки свой номер и число проверок постоянно растет
Size: a a a
2020 July 24
DG
Ну в исходной задаче же сказано - 20 признаков со значением 0 или 1
И как поможет b-tree индекс в поиске “всех строк, где 4-й бит единица, а остальные - не важно”?
DG
С селективностью по этому биту 50% вы получите 50% строк в виде результата.
АЛ
И как поможет b-tree индекс в поиске “всех строк, где 4-й бит единица, а остальные - не важно”?
Никак, однако при явно заданном параметре - не прошел вот такие-то ФЛК (остальные прошел) - это работает
АЛ
Для остальных вариантов можно сделать функциональные индексы - которые будут не хуже чем составные при хранении в отдельных полях
DG
Да, так можно. Но тогда вроде и не остается преимуществ перед просто несколькими бинарными полями.
АЛ
Я видел такую реализацию на хранении информации о прохождении ФЛК. Там много всяких проверок - у каждой проверки свой номер и число проверок постоянно растет
В применении к этому варианту - добавление нового флага не трубует добавление поля и это может быть удобно при создании новых ФЛК в интерфейсе пользователя. Знаю, что это можно сделать множеством других способов.
V
мне теперь самому стало интересно, можно хотябы парочку?
У клиента выставлена определенная таймзона, не соответствующая серверной; используется view с at time zone; на сервере postgres устаревший список таймзон, отличный от системной; кривые таймзоны на клиенте
V
Ещё может быть каскадный at time zone, возможно неявный
IZ
Хотя нет, пусть вакуха потонет в трафике, так ей и надо
s
Будут ли они эффективнее чем индекс по 1 числовому полю?
Это не так работает
s
Будете хранить как число и вам придется для поиска по одному признаку перечислять все возможные варианты чисел, в которых этот бит в нужно значении. При 20 признаках и поиске по одному признаку это 2^19 чисел получится какбе. Ну точнее подрезать варианты можно, но в худшем случае оно будет так.
s
Либо строить функциональные индексы, но тогда один хрен их будет 20, просто ещё и фарш с упаковкой признаков добавите бессмысленный
s
Зато в случае отдельных полей может получиться закономерности в запросах выловить и часть индексов вообще partial сделать.
АЛ
Мы выше это уже обсудили
АЛ
Не серебрянная пуля это точно
2020 July 25
Ð
Всем добрый день
Хочу придумать функцию для поля в бд, в которой можно хранить разные значения
чтобы не было массивом в стиле [1,3,5]
Всего пунктов около 10-20
выше пример не очень, сложно делать поиск, да и это строка (json не особо хорошо юзать в бд)
думал над тем, чтобы сделать в стиле битов
1000000010101
слева ведущий бит. но число будет длинное. как можно укоротить?
хочу чтобы быстро считывало (вариант с битами хорош тем, что можно деление юзать)
ну и меньше места занимало
Хочу придумать функцию для поля в бд, в которой можно хранить разные значения
чтобы не было массивом в стиле [1,3,5]
Всего пунктов около 10-20
выше пример не очень, сложно делать поиск, да и это строка (json не особо хорошо юзать в бд)
думал над тем, чтобы сделать в стиле битов
1000000010101
слева ведущий бит. но число будет длинное. как можно укоротить?
хочу чтобы быстро считывало (вариант с битами хорош тем, что можно деление юзать)
ну и меньше места занимало
это делается отдельной таблицей флагов, или массивом в поле таблицы. Вариант с жсон - еще хуже массива. А битовые флаги это путь либо к фуллсканам, либо к запросам с перечнем вариантов, как указано выше, либо к появлению отдельного индекса на каждую комбинацию флагов, но зато сами данные будут компактно лежать на диске
@
Всем привет. Вопрос, ребят. Можно ли:
Или как обновлять и сразу получать обновленное
UPDATE table SET row1=? WHERE id=? RETURNING row2, row3 ?Или как обновлять и сразу получать обновленное
KK
а смысл? если вы заведомо знаете значения переменных
@
я обновляю одно значение, получаю две других