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

Откуда: с болот
Сообщений: 3061
kdv
господи, hash join нужен, когда НЕТ ПОДХОДЯЩИХ ИНДЕКСОВ, чтобы не строить их, а потом удалять. А иногда индексы вообще нельзя построить (по результатам селективных процедур - для этого результат надо было бы сначала сохранить)
Именно об этом я и говорил!
То есть, HASH JOIN нужен при отсутствии индексов и/или при часто переиспользуемых в запросе наборов строк, получаемых подзапросами - производных таблиц. Так ведь? Я достаточно корректно изложил?
30 сен 19, 20:28    [21983208]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1711
rdb_dev,

а почему, например, не join с небольшой таблицей по PK?
30 сен 19, 20:32    [21983215]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Дегтярев Евгений, не понял вопроса. Поясни пожалуйста.
30 сен 19, 20:37    [21983221]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1711
rdb_dev,

справочная таблица джойнится по первичному ключу с основной выборкой
можно здесь использовать хеш джойн?
30 сен 19, 20:44    [21983227]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28320
Дегтярев Евгений,

я пишу - "когда нет подходящих индексов", он пишет - "справочная таблица джойнится по первичному ключу"...
моя твоя не понимай? что в приведенных мной примерах непонятного?
Сколько надо дней или часов, чтобы взять две таблицы, с индексами по полям связи, и
тремя запросами по +0 перепробовать отрубание индекса с одной стороны, с другой стороны и с обоих сторон,
и посмотреть на планы запросов в 3.0?
Кажись, не больше пары минут...
30 сен 19, 20:47    [21983233]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Дегтярев Евгений
rdb_dev,

справочная таблица джойнится по первичному ключу с основной выборкой
можно здесь использовать хеш джойн?
Почему нет? Использовать можно, вопрос только - зачем?
30 сен 19, 20:49    [21983238]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Дмитрий, у меня возникает резонный вопрос - если мы, при отсутствии подходящих индексов связываем производные таблицы по полям, хранящим числа на основе BIGINT, DOUBLE PRECISION, TIMESTAMP и т.д., почему не использовать эти значения, как ключи ассоциативного массива? Зачем надо напрягать процессор вычислением результатов хэш-функций по этим полям?
30 сен 19, 20:59    [21983240]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28320
rdb_dev,

я всегда предлагаю представить себе join на пальцах. Надо растопырить две ладони.
И потом представить, как можно по очереди каждому пальцу одной руки сопоставить пальцы другой.
Ответ - только полным перебором пальцев одной руки.

то есть, plan (a natural, b natural).

Мне интересно, каким образом значения столбца в a можно использовать "как индекс", если эти значения - никак не сортированные?
30 сен 19, 21:02    [21983242]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28320
rdb_dev,

к примеру, есть 5 записей

2
7
4
1
8

как этот массив можно использовать "как ключи ассоциативного массива"?
30 сен 19, 21:04    [21983243]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10142
rdb_dev
То есть, HASH JOIN нужен при отсутствии индексов


не только.

1. доступ по индексу вытесняет страницы из кеша, когда его мало
2. одна и та же страница может быть прочитана многократно
3. если хеш таблицы независимы их можно строить параллельно

select count(*)
from horse
join color on horse.code_color = color.code_color


План
PLAN JOIN (COLOR NATURAL, HORSE INDEX (FK_HORSE_COLOR))

------ Информация о производительности ------
Время подготовки запроса = 16ms
Время выполнения запроса = 531ms
Среднее время на получение одной записи = 531,00 ms
Current memory = 36 801 408
Max memory = 37 028 784
Memory buffers = 2 048
Reads from disk to cache = 34 053
Writes from cache to disk = 1
Чтений из кэша = 482 764

Select Expression
-> Aggregate
-> Nested Loop Join (inner)
-> Table "COLOR" Full Scan
-> Filter
-> Table "HORSE" Access By ID
-> Bitmap
-> Index "FK_HORSE_COLOR" Range Scan (full match)

select count(*)
from horse
join color on horse.code_color+0 = color.code_color+0


План
PLAN HASH (HORSE NATURAL, COLOR NATURAL)

------ Информация о производительности ------
Время подготовки запроса = 15ms
Время выполнения запроса = 391ms
Среднее время на получение одной записи = 391,00 ms
Current memory = 36 801 408
Max memory = 37 028 784
Memory buffers = 2 048
Reads from disk to cache = 4 657
Writes from cache to disk = 1
Чтений из кэша = 451 915

Select Expression
-> Aggregate
-> Filter
-> Hash Join (inner)
-> Table "HORSE" Full Scan
-> Record Buffer (record length: 25)
-> Table "COLOR" Full Scan

Обрати внимание на Reads from disk to cache

На всякий случай если ты думаешь оптимизатор не тот индекс выбрал

select count(*)
from horse
join color on horse.code_color+0 = color.code_color


PLAN JOIN (HORSE NATURAL, COLOR INDEX (PK_COLOR))

------ Информация о производительности ------
Время подготовки запроса = 32ms
Время выполнения запроса = 781ms
Среднее время на получение одной записи = 781,00 ms
Current memory = 36 802 016
Max memory = 37 028 784
Memory buffers = 2 048
Reads from disk to cache = 4 656
Writes from cache to disk = 1
Чтений из кэша = 1 750 817

Select Expression
-> Aggregate
-> Nested Loop Join (inner)
-> Table "HORSE" Full Scan
-> Filter
-> Table "COLOR" Access By ID
-> Bitmap
-> Index "PK_COLOR" Unique Scan

Reads уменьшилось, но время в двое больше
30 сен 19, 21:05    [21983244]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10142
теперь ставим нормальный кеш

select count(*)
from horse
join color on horse.code_color = color.code_color


План
PLAN JOIN (COLOR NATURAL, HORSE INDEX (FK_HORSE_COLOR))

------ Информация о производительности ------
Время подготовки запроса = 32ms
Время выполнения запроса = 265ms
Среднее время на получение одной записи = 265,00 ms
Current memory = 558 485 072
Max memory = 558 686 336
Memory buffers = 32 768
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 482 764

select count(*)
from horse
join color on horse.code_color+0 = color.code_color+0


План
PLAN HASH (HORSE NATURAL, COLOR NATURAL)

------ Информация о производительности ------
Время подготовки запроса = 32ms
Время выполнения запроса = 359ms
Среднее время на получение одной записи = 359,00 ms
Current memory = 558 490 832
Max memory = 558 686 336
Memory buffers = 32 768
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 451 915

rdb_dev,

видишь?
30 сен 19, 21:09    [21983247]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
kdv
Мне интересно, каким образом значения столбца в a можно использовать "как индекс", если эти значения - никак не сортированные?
Также, как при использовании хэш-таблицы, в которой каждому значению ключа (каждому результату хэш функции по связываемому столбцу) соответствует строка... Только вместо хэша реальное значение, чтобы не нагружать попусту процессор.
30 сен 19, 21:10    [21983248]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Симонов Денис
1. доступ по индексу вытесняет страницы из кеша, когда его мало
Давай не будем перетирать по кругу одно и тоже. 21982658
30 сен 19, 21:19    [21983254]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10142
rdb_dev
почему не использовать эти значения, как ключи ассоциативного массива?


ты совсем не догоняешь? Какие реализации ассоциативного массива по твоему существуют?
Подскажу маленькую тайну, ассоциативный массив обычно и реализован внутри как хеш-таблица
30 сен 19, 21:21    [21983258]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 60315
Вы допрыгаетесь лишь до того, что всё это
почистят нахфиг, все последние страницы.

Posted via ActualForum NNTP Server 1.5

30 сен 19, 21:24    [21983261]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

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

rdb_dev
вместо хэша реальное значение, чтобы не нагружать попусту процессор.

Вычисление CRC32 дешевле, чем распознавание случаев когда в качестве хэш-функции можно
вместо него использовать f(x)=x.

Posted via ActualForum NNTP Server 1.5

30 сен 19, 21:26    [21983262]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

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

а чего тут перетирать то. Ну если ты не читаешь статью про методы доступа. Ну почитай там про стратегии кеша и когда она меняется.
А заодно подумай почему индекс может читать одни и те же страницы многократно при JOIN.

Да сейчас Firebird не имеет достаточно оценочных параметров в оптимизаторе чтобы решить когда нужен HASH JOIN, а когда NESTED LOOP по индексу. Поэтому и сделано есть индекс по индексу, нет хеш-джойн. При достаточном кэше это нормально работает, по крайней мере если и промахивается, то не сильно.
30 сен 19, 21:27    [21983266]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

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

Dimitry Sibiryakov
использовать f(x)=x.

Кроме того эта функция может дать худшее распределение по слотам, чем CRC32.

Posted via ActualForum NNTP Server 1.5

30 сен 19, 21:28    [21983269]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 60315
Симонов Денис> Да сейчас Firebird не имеет достаточно оценочных параметров в оптимизаторе
Симонов Денис> чтобы решить когда нужен HASH JOIN, а когда NESTED LOOP по индексу.

Шо, правда, до сих пор не имеет ?

Posted via ActualForum NNTP Server 1.5

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

Откуда: с болот
Сообщений: 3061
Симонов Денис
Подскажу маленькую тайну, ассоциативный массив обычно и реализован внутри как хеш-таблица
Не надо мне маленьких тайн!
Ты лучше объясни - в чём для алгоритма оптимизации поиска отличие использования в качестве ключа ассоциативного массива BIGINT результата хэш-функции по полю BIGINT или реального значения этого поля?
30 сен 19, 21:30    [21983272]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Гаджимурадов Рустам
Вы допрыгаетесь лишь до того, что всё это
почистят нахфиг, все последние страницы.
Тебе жалко чтоль?
30 сен 19, 21:30    [21983273]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 3061
Dimitry Sibiryakov
Вычисление CRC32 дешевле, чем распознавание случаев когда в качестве хэш-функции можно
вместо него использовать f(x)=x.
Это утверждение годится только для байтовой последовательности, имеющей размер больше, чем 32 бита, а если ты точно знаешь, что байтовая последовательность всех значений конкретного поля не превышает 32 бит, то зачем рассчитывать CRC32?
30 сен 19, 21:34    [21983277]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

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

ты видел случаи, когда HASH JOIN выбирается осознано вместо NESTED LOOP по индексу? Я нет.
ИХМО оптимизатор не оперирует понятием достаточности кеша, он оптимистично полагает, что кеш резиновый
30 сен 19, 21:35    [21983281]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

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

rdb_dev
в чём для алгоритма оптимизации поиска отличие использования в качестве ключа
ассоциативного массива BIGINT результата хэш-функции по полю BIGINT или реального значения
этого поля?

Повторяю медленно: равномерность распределения значений в диапазоне [0..размер
хэш-таблицы]. Это второе по значению требование к хэш-функциям, используемым для хэш-таблиц.

Posted via ActualForum NNTP Server 1.5

30 сен 19, 21:36    [21983282]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

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

rdb_dev
а если ты точно знаешь, что байтовая последовательность всех значений конкретного поля не
превышает 32 бит, то зачем рассчитывать CRC32?

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

Posted via ActualForum NNTP Server 1.5

30 сен 19, 21:39    [21983285]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 38 39 40 41 42 [43] 44 45 46 47 .. 50   вперед  Ctrl
Все форумы / Firebird, InterBase Ответить