У нас то же самое. То же пришли к канбану.
Только похоже дальше продвинулись.
Чего будет дальше:
1. Этап моделирования архитектором, после анализа. Нужно когда разработчиков много, проект большой, и реализацию нужно выполнить правильно, с точки зрения архитектуры системы.
2. Этап ревью. Ну тут понятно. У нас не только техническое ревью, но и даже ревью анализа есть.
3. Полноценный этап тестирования. Ни какой uat не проведет регрес тестирование и не проверит, что не поломалось старое, или соседнее или еще что-нить. Да и вообще полноценные тест кейсы надежнее чем Uat который зачастую идет «на глаз». Но UAT никто не отменяет!!!
Да. Тестовые данные надо подправить. Возьмем так, чтобы id был адекватным:
insert into public.test1
select generate_series(1,1000000), 1000000-generate_series(1,1000000), 'abcdef';
/*Плюс пару индексов:*/
create index ix_test1_id2 on public.test1 (id2);
create index ix_test1_id on public.test1 (id);
— 1. Запрос из первого коментария у меня работал быстро, но ровно до момента когда я не вставил в public.test2
40 тысяч записей. Он вообще перестал выполнятся!!! На 30к за полсекунды, а на 40к — стоп. Ни разу не отработал даже за 10 минут, сколько ни запускал.
Его план ни о чем мне не говорит, что такое Filter: ((hashed SubPlan 1) OR (hashed SubPlan 2)) ???
Это видимо тоже какие-то хэш таблцицы в памяти, но явно есть отличие от хэш джоина, возможно нет spill на диск?? Кто просветит механику?
— 2. Запрос из второго коментария конечно интереснее.
Он действительно может быть быстрее, за счет лукапа по индексам в большую таблицу, но
1.) Нужны 2 больших индекса, хотя они скорее всего там и так возможно будут, но если их нет — вариантов нет.
2.) Все таки начиная с какого-то объема таблицы 2 — у меня уже с 200к, запрос с хэш джоином обгоняет его.
Всеже рандомные чтения в разы медленнее секвенс скана. Ну а если вообще планируется выбрать всю большую таблицу — без вариантов лукапить её по одной строке — плохо.
3.) В этом запросе inner join — он позволяет при Nested Loop менять входные таблицы. Если заменить джоин на LEFT OUTER JOIN —
nested loop не сможет поменять входные таблицы местами — и план будет такой как в моем пример — медленный. Тут тоже только 2 hash join-а помогут, в этом случае left работает так же как и иннер.
А так естественно нужно просто знать все варианты и использовать по месту нужный!!!
Только похоже дальше продвинулись.
Чего будет дальше:
1. Этап моделирования архитектором, после анализа. Нужно когда разработчиков много, проект большой, и реализацию нужно выполнить правильно, с точки зрения архитектуры системы.
2. Этап ревью. Ну тут понятно. У нас не только техническое ревью, но и даже ревью анализа есть.
3. Полноценный этап тестирования. Ни какой uat не проведет регрес тестирование и не проверит, что не поломалось старое, или соседнее или еще что-нить. Да и вообще полноценные тест кейсы надежнее чем Uat который зачастую идет «на глаз». Но UAT никто не отменяет!!!
— 1. Запрос из первого коментария у меня работал быстро, но ровно до момента когда я не вставил в public.test2
40 тысяч записей. Он вообще перестал выполнятся!!! На 30к за полсекунды, а на 40к — стоп. Ни разу не отработал даже за 10 минут, сколько ни запускал.
Его план ни о чем мне не говорит, что такое Filter: ((hashed SubPlan 1) OR (hashed SubPlan 2)) ???
Это видимо тоже какие-то хэш таблцицы в памяти, но явно есть отличие от хэш джоина, возможно нет spill на диск?? Кто просветит механику?
— 2. Запрос из второго коментария конечно интереснее.
Он действительно может быть быстрее, за счет лукапа по индексам в большую таблицу, но
1.) Нужны 2 больших индекса, хотя они скорее всего там и так возможно будут, но если их нет — вариантов нет.
2.) Все таки начиная с какого-то объема таблицы 2 — у меня уже с 200к, запрос с хэш джоином обгоняет его.
Всеже рандомные чтения в разы медленнее секвенс скана. Ну а если вообще планируется выбрать всю большую таблицу — без вариантов лукапить её по одной строке — плохо.
3.) В этом запросе inner join — он позволяет при Nested Loop менять входные таблицы. Если заменить джоин на LEFT OUTER JOIN —
nested loop не сможет поменять входные таблицы местами — и план будет такой как в моем пример — медленный. Тут тоже только 2 hash join-а помогут, в этом случае left работает так же как и иннер.
А так естественно нужно просто знать все варианты и использовать по месту нужный!!!