Нужно перевести строку вида "0fad933379d52044" в int (bigint). Средствами базы данных.
Желательно без сложной хранимой процедуры....
Вообще же, задача более общая на самом деле. Есть большая табличка, пока что она 25 лямов записей, но будет расти.
Табличка с двумя полями: id (primay key) и some_txt_key varchar(150), по some_txt_key построен индекс.
Поиск по полю some_txt_key, несмотря на использование индекса, заметно(!) тормознее чем поиск по аналогичным табличкам по полю int8.
Хочу прикрутить вспомогательное поле с int8 в котором будет мой хеш от строки, и дальше поиск организовать по двум полям (ну с учетом там все холлизий разумеется).
По идее субд должна бы сама деелать эффективный хеш, и искать строку так же быстро как и int8, но по каким-то причинам этого не делает.
Посоветуйте или как правильно отиндексировать табличку, или способ как мне из md5(some_txt_key) получить int8.
Спасибо!
Здравствуйте, Аноним, Вы писали:
А>Нужно перевести строку вида "0fad933379d52044" в int (bigint). Средствами базы данных.
А>Желательно без сложной хранимой процедуры....
Без хранимки не получится. В
стандартных строковых функциях ничего полезного нет. Так что что-нибудь написать придется. Просуммировать коды символов с коэффициентами, например. Может быть (если архитектура позволяет) вообще вычислять на стороне клиента а не базы.
А>По идее субд должна бы сама деелать эффективный хеш, и искать строку так же быстро как и int8, но по каким-то причинам этого не делает.
А у вас индекс то как создан? Хэшированный или обычный BTree? Если вдруг решите использовать хэш-индекс, внимательно читайте документацию. Вроде бы есть какие-то неочевидные ограничения и подводные камни.
А>Посоветуйте или как правильно отиндексировать табличку, или способ как мне из md5(some_txt_key) получить int8.
explain analyze для вашего запроса покажите (или хотя бы обычный explain). Может, селективность индекса плохая получается. Или он не анализируется/не обновляется статистика. Эти две причины приведут к тому, что индекс не используется. Или ваши 150 символов приходится в индекс с диска таскать часто, например.
Можете для вашего md5 посчитать какой-нибудь crc восьмибитный. Но лучше бы crc считать по исходным данным либо по бинарному представлению md5, а не по его текстовому представлению (текстовое представление распределено "плохо").
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>>Нужно перевести строку вида "0fad933379d52044" в int (bigint). Средствами базы данных.
А>>Желательно без сложной хранимой процедуры....
M>Без хранимки не получится. В стандартных строковых функциях ничего полезного нет. Так что что-нибудь написать придется. Просуммировать коды символов с коэффициентами, например. Может быть (если архитектура позволяет) вообще вычислять на стороне клиента а не базы.
А>>По идее субд должна бы сама деелать эффективный хеш, и искать строку так же быстро как и int8, но по каким-то причинам этого не делает.
M>А у вас индекс то как создан? Хэшированный или обычный BTree? Если вдруг решите использовать хэш-индекс, внимательно читайте документацию. Вроде бы есть какие-то неочевидные ограничения и подводные камни.
А>>Посоветуйте или как правильно отиндексировать табличку, или способ как мне из md5(some_txt_key) получить int8.
M>explain analyze для вашего запроса покажите (или хотя бы обычный explain). Может, селективность индекса плохая получается. Или он не анализируется/не обновляется статистика. Эти две причины приведут к тому, что индекс не используется. Или ваши 150 символов приходится в индекс с диска таскать часто, например.
M>Можете для вашего md5 посчитать какой-нибудь crc восьмибитный. Но лучше бы crc считать по исходным данным либо по бинарному представлению md5, а не по его текстовому представлению (текстовое представление распределено "плохо").
select ('x' || '0fad933379d52044')::bit(64)::int8
