Кстати формат даты '20110101' (yyyymmdd) работает везде где я видел от mssql до постгреса, от фаерберда, до оракла.! (Если знаете исключения — пишите). Я его как стандарт всегда использую.
И я скромное имхо добавлю. Много разных баз видел. На разных субд. От богом забытого Informix-a до mssql и oraсle, от firebird до netezza. И в общем случае хочу заметить, что никаких общих случаев нет. Всегда все по разному. Где-то надо одно, где-то другое. В каком-то случае конкретный баг — настолько критичен, что хоть базу меняй. А в другом месте, с ним не столкнутся никогда за все время использования. Но там будут свои грабли.
Конечно это я тут капитанствую, но вывод простой — даже самый маленьки баг может быть кому очень критичен. И наоборот — другой баг казалось бы жесть, как работать вообще можно — а у кого-то даже кейса такого никогда не возникнет за 10 лет использования.
может у мускуля статистики нет? Если например в вашей таблице меньше 40 записей с rating > 50 and is_published=1 — то как раз поиск по индексу по (is_published, rating ) будет куда оптимальнее, ибо по published_at придется ВСЕ записи просканить.
Как раз таки я очень понимаю разницу с т.з заказчика. В итеративной модели быстро можно увидеть всю картину (недоделанную, нетестированную, с багами, но всю!) Это очень, скажем так — воодушевляет заказчика (на самом деле). А когда частями — некоторые части не увидеть совем до последнего дедалйна — и если эта часть внезапно совсем не то что надо — может быть поздно!
Не понял. Если мускл тут будет индекс по рейтингу и is_published использовать — сортировать по-любому. Или вы хотите индекс по published_at использовать?
3. Внутри каждой фичи они разрабатываются водопадно?? или как?
4. Вообще не понял. А в любой другой модели нельзя рисовать uml и генерить код визуально, так чтоли?
5. Хм… вом мы как бы инкрементально по фичам работаем и каждый день митинги проводим — это аджайл или нет?
Как-то не очевидны отличия между этими моделями.
Вот давайте на примере, по простому:
Если мы имеем
1. Есть новый кусок требований у заказчика:
2. Аналитики проанализировали, написали какое-то ТЗ на разработку
3. Разработчики разработали
4. Тестировщики оттестировали
5. Выкатили в прод, заказчик посмотрел и появились новые требования
— и дальше Go To 1
Это вот какая модель разработки??? Водопад или итерационная? Или спиральная. Я как-то теряюсь.
И как она будет выглядить во всех 7 разных вариантах.
хинт /* parralels */ это вообще не из этой оперы. Он выполняет параллелизацию запроса, наример сканы, сортировки и группировки, инсерт, балк лоад и т.п.
У нас то же самое. То же пришли к канбану.
Только похоже дальше продвинулись.
Чего будет дальше:
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 работает так же как и иннер.
А так естественно нужно просто знать все варианты и использовать по месту нужный!!!
Конечно это я тут капитанствую, но вывод простой — даже самый маленьки баг может быть кому очень критичен. И наоборот — другой баг казалось бы жесть, как работать вообще можно — а у кого-то даже кейса такого никогда не возникнет за 10 лет использования.
4. Вообще не понял. А в любой другой модели нельзя рисовать uml и генерить код визуально, так чтоли?
5. Хм… вом мы как бы инкрементально по фичам работаем и каждый день митинги проводим — это аджайл или нет?
Вот давайте на примере, по простому:
Если мы имеем
1. Есть новый кусок требований у заказчика:
2. Аналитики проанализировали, написали какое-то ТЗ на разработку
3. Разработчики разработали
4. Тестировщики оттестировали
5. Выкатили в прод, заказчик посмотрел и появились новые требования
— и дальше Go To 1
Это вот какая модель разработки??? Водопад или итерационная? Или спиральная. Я как-то теряюсь.
И как она будет выглядить во всех 7 разных вариантах.
p.s. Реально хочется разобраться, без наезда!
Только похоже дальше продвинулись.
Чего будет дальше:
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 работает так же как и иннер.
А так естественно нужно просто знать все варианты и использовать по месту нужный!!!