Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 41 42 43 44 45 [46] 47 48 49 50   вперед  Ctrl
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
rdb_dev
Dimitry Sibiryakov, зачем вообще делить по модулю результат хэш-функции, когда достаточно просто экранировать старшие младшие биты оставив только необходимые для адресации слотов, несколько модифицировав значение? При условии, что хэш-таблица имеет 10 слотов, можно сделать что-то типа ((hash(x) & 0x0F) - 10) & 0x0F, что наверняка быстрее чем деление по модулю.
1 окт 19, 14:47    [21983927]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10142
rdb_dev,

само по себе что-то там распределить целью не является. Это просто свойство хеш-таблиц.
Цель быстрый поиск по заданному или заданным ключам. Именно поэтому они так распространены.
1 окт 19, 14:56    [21983941]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Симонов Денис, полагаю, здесь ты заблуждаешься. При недостаточно большом количестве выделенных слотов, но большом количестве строк, в каждом слоте будет весьма приличное кол-во записей, по значениям соединяемых полей в которых СУБД придётся пробегать NATURAL'ом, что будет отрицательно сказываться на скорости HASH JOIN. Поэтому, основное свойство хэш-таблицы, в данном случае, это именно равномерное распределение.
1 окт 19, 15:09    [21983956]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48652

rdb_dev
что наверняка быстрее чем деление по модулю.

"Быстрее" не значит "лучше". Размер хэш-таблицы обычно делают простым числом.

Posted via ActualForum NNTP Server 1.5

1 окт 19, 15:29    [21983990]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1711
rdb_dev
Удивляет другое - ни от кого из вас я не услышал внятного объяснения - зачем возиться с хэшами. Оказалось, что дело не столько в скорости выполнения HASH JOIN по сравнению с обычным JOIN на обычных индексах, сколько в возможности более-менее равномерно распределить значения ключей по количеству слотов в ограниченном пространстве ключей. Видимо, вы тоже были не в курсе.

передергиваешь... треп за хеши начал ты
а дело таки в скорости
1 окт 19, 15:29    [21983991]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10142
rdb_dev,

нет там никаких NATURAL. По второму кругу пошли. То что записано в хеш таблицу уже не нуждается в обращении через страничный кеш.

Будет один раз проход NATURAL для построения хеш таблицы (по меньшей таблице) и второй NATURAL при её пробировании (по большей таблицы).

Обрабортка коллизий это ни разу не NATURAL (ну по крайней мере так назвать нельзя), там уже другими категориями надо мыслить.
Опять же я говорил что коллизии можно отсортировать в момент добавления чтобы делать по ним бинарный поиск.

Ну и никто размер хеш-таблицы равный 10 не выбирает. Обычно это простое число довольно большое (как минимум десятки тысяч).
Так что указанный тобой недостаток проявляется только если хеш-таблицу строить по таблицам миллионикам. Против этого тоже есть средства борьбы, например перестроить таблицу, если слотов оказалось мало.
1 окт 19, 15:31    [21983996]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1711
rdb_dev
можно сделать что-то типа ((hash(x) & 0x0F) - 10) & 0x0F, что наверняка быстрее чем деление по модулю.

а ты проверь
1 окт 19, 15:32    [21984000]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Dimitry Sibiryakov, без тестов или математического обоснования мы этого не узнаем.
1 окт 19, 15:34    [21984006]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Симонов Денис, знакомые с исходниками могут сказать точнее.
1 окт 19, 15:36    [21984014]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10142
rdb_dev,

мне кажется ты их так достал, что они вряд ли будут отвечать
Ну и Dimitry Sibiryakov в некоторой степени с исходниками знаком.
1 окт 19, 15:40    [21984019]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1711
Dimitry Sibiryakov
Размер хэш-таблицы обычно делают простым числом.

Экспериментировал с реализацией хештаблицы с открытой адресацией, т.к. набор ключей после создания не менялся, было интересно получить более высокий фактор заполнения. На сколько помню, удалось достичь фактора заполнения больше 0.8 и макс кол-ве проб = 10, когда размер был степенью двойки.
1 окт 19, 15:40    [21984020]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48652

rdb_dev
без тестов или математического обоснования мы этого не узнаем.
Ну так проводи свои тесты и гугли это самое обоснование. Мне достаточно того, что я
это уже проделал в прошлом.

Posted via ActualForum NNTP Server 1.5

1 окт 19, 15:43    [21984024]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Симонов Денис, если кто-нибудь сразу, по-человечески ответил на вопрос - зачем возиться с хэшами, я бы никого не доставал. Логично? :)
1 окт 19, 15:44    [21984026]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48652

rdb_dev
если кто-нибудь сразу, по-человечески ответил на вопрос - зачем возиться с хэшами

Тебе разве сразу не сказали "ради быстродействия"?.. Или для тебя это недостаточно
"по-человечески"?..

Posted via ActualForum NNTP Server 1.5

1 окт 19, 15:47    [21984034]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Dimitry Sibiryakov, конечно недостаточно! Давай не будем начинать по кругу? Все вопросы давно уже заданы и можно просто почитать.
1 окт 19, 15:52    [21984039]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48652

rdb_dev
конечно недостаточно!

Тогда все остальные ответы тоже не имеют смысла. И давать их по второму кругу никто не
будет - можно просто прочитать.

Posted via ActualForum NNTP Server 1.5

1 окт 19, 15:54    [21984042]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 30631

ну чо, фонтан из сяк?

Posted via ActualForum NNTP Server 1.5

1 окт 19, 16:40    [21984097]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1711
Мимопроходящий
ну чо, фонтан из сяк?

Ну мы же распределили равномерно ключи по слотам более-менее
1 окт 19, 18:26    [21984235]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 654
rdb_dev
Симонов Денис, если кто-нибудь сразу, по-человечески ответил на вопрос - зачем возиться с хэшами, я бы никого не доставал. Логично? :)


Не-а.
1 окт 19, 18:38    [21984249]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Старый плюшевый мишка
Member

Откуда:
Сообщений: 654
Мимопроходящий
ну чо, фонтан из сяк?


ИмпоссИбль.
1 окт 19, 18:39    [21984250]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 60315
Мимопроходящий> ну чо, фонтан из сяк?

Не иссяк, а устал. Щас ещё силёнок подкопит и по новой.

Posted via ActualForum NNTP Server 1.5

1 окт 19, 18:56    [21984278]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Vlad F
Member [заблокирован]

Откуда:
Сообщений: 1008
Гаджимурадов Рустам,

Лучше не надо.))
https://dic.academic.ru/dic.nsf/dic_wingwords/814/Если
1 окт 19, 20:58    [21984352]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Tonal
Member

Откуда: Новосибирск
Сообщений: 180
По мативам Разделить значение через запятую .
А вот если бы оператор IN Умел работать с массивами, и последнюю размерность массива можно было бы не указывать, то заявленный запрос
select A.X, B.NAME
from A
left join B on B.ID in (A.X)
where A.ID=:ID

При объявлении A.X массивом работал бы именно в таком интуитивном варианте.
8 ноя 19, 16:12    [22012454]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Vlad F
Member [заблокирован]

Откуда:
Сообщений: 1008
Tonal,

Это все, имхо, мелочи жизни. Для начала надо просто просить обеспечить саму возможность манипулирования массивами в DML.
Кстати, кто в курсе, подобный тикет на трекере есть?
8 ноя 19, 16:27    [22012474]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10142
Vlad F,

лучше сразу поддержку JSON просить
8 ноя 19, 17:01    [22012496]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 41 42 43 44 45 [46] 47 48 49 50   вперед  Ctrl
Все форумы / Firebird, InterBase Ответить