forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Для PostgreSQL представлена реализация условных индексов, opennews (?), 25-Июн-15, (0) [смотреть все]

Не скажу за полезность этого решения, но вот как за шаблон кода для создания вир, ъ (?), 18:13 , 25-Июн-15, (1)
грязный хак какой-то, edo (ok), 18:29 , 25-Июн-15, (2) –1
То есть он умеет только EXPLAIN без ANALYZE Похоже на попытку использовать как, rshadow (ok), 18:33 , 25-Июн-15, (3) +1 //

Если есть возможность использовать машинно-реализуеамый костыль вместо мозгов - , Crazy Alex (ok), 19:14 , 25-Июн-15, (5) //

Ну так какой смысл-то в использовании этого конкретного костыля Наплодить автом, rob pike (?), 21:46 , 25-Июн-15, (11) +2 //

Почему 100500 Наплодить столько, сколько позволено настройками Например, для O, Crazy Alex (ok), 22:32 , 25-Июн-15, (12)

Ну вот только для ORM разве что Получится, правда, всё равно как всегда - ANALY, rob pike (?), 23:41 , 25-Июн-15, (13)

Получится так, как будет в инструкции к ORM Да, с какого-то момента - звать DBA, Crazy Alex (ok), 00:11 , 26-Июн-15, (15)

Примерно 99 развития IT в этом и заключается , rob pike (?), 00:01 , 26-Июн-15, (14)
EXTERMINATE, uze (?), 09:36 , 26-Июн-15, (18)

не прошло и четверти века после создания sx driver-ов, manster (ok), 19:06 , 25-Июн-15, (4) –2
Virtual Index in Memory, ваш КЭП , Аноним (-), 20:26 , 25-Июн-15, (7)
следующий шаг - сделать так, чтоб analyze говорил, где ему не хватает индексов и, None (??), 01:06 , 26-Июн-15, (16) //

в других субд есть такая методика, capture missing index statistics , близняшко (?), 11:25 , 26-Июн-15, (19)
И приделать ему телепатию чтобы он знал что такое оптимальный запрос для наших к, rob pike (?), 11:36 , 26-Июн-15, (20) +1

Да лучше бы пакеты запилили, Аноним (-), 02:24 , 26-Июн-15, (17)
Чуть не перепутал с partial index , orgkhnargh (ok), 17:11 , 26-Июн-15, (21)

Сообщения [Сортировка по времени | RSS]

5. "Для PostgreSQL представлена реализация условных индексов" +/–

Сообщение от Crazy Alex (ok), 25-Июн-15, 19:14

Если есть возможность использовать машинно-реализуеамый костыль вместо мозгов - надо её использовать. Такой костыль может использоваться самой машиной, мозги - только в комплекте с живым человеком.

Ответить | Правка | Наверх | Cообщить модератору

11. "Для PostgreSQL представлена реализация условных индексов" +2 +/–

Сообщение от rob pike (?), 25-Июн-15, 21:46

Ну так какой смысл-то в использовании этого конкретного костыля? Наплодить автоматически 100500 индексов, чтоб insert потом застрелился от безнадеги?
Ладно бы опции CONCURRENTLY у CREATE INDEX не было, так ведь есть же.
Нужен индекс - сделай. Не нужен - не сделай. Нужен, сделал, не используется планировщиком - подкрути статистику (http://www.depesz.com/2013/05/30/explaining-the-unexplainabl.../)

Ответить | Правка | Наверх | Cообщить модератору

12. "Для PostgreSQL представлена реализация условных индексов" +/–

Сообщение от Crazy Alex (ok), 25-Июн-15, 22:32

Почему 100500? Наплодить столько, сколько позволено настройками. Например, для ORM - милое дело, пожалуй, будет. Супер-производительности, может, и не будет - но зато автоматом. Ну и вообще это правильное направление, примерно как компиляторы в своё время хуже, чем люди, ассемблерный код генерили, а теперь - человек в состоянии посостязаться только на небольших кусках, и далеко не всякий.

Ответить | Правка | Наверх | Cообщить модератору

13. "Для PostgreSQL представлена реализация условных индексов" +/–

Сообщение от rob pike (?), 25-Июн-15, 23:41

Ну вот только для ORM разве что. Получится, правда, всё равно как всегда - ANALYZE никто делать не будет, статистику крутить не будет, половина индексов будут медленнее seqscan-а. Зато можно написать "наш ORM умеет ого-го, приходить в сознание с ним вообще необязательно". Потом всё равно звать DBA со стороны и платить $200 в час чтоб как-то заворочалось.
С ассемблером всё осталось ровно так же, потому что замок эволюционирует не медленней ключа.
Во-первых, современный Haswell - он уже сильно умнее Сишного компилятора во многих местах (если не сказать "во всех"), причём недетерминированность проявляется и в этом - то есть оптимизация превращается в угадайку - кто угадал насколько тупого кода ему надо в этом конкретном месте с этими конкретными данными, чтобы он сказал "ага! я знаю этот паттерн!" и оптимизировал, тот и молодец. Что в подавляющем большинстве случаев выражается в практичности подхода "всё что мы можем осмысленно сделать - это добиться того чтобы этот чанк кода помещался в кэш" (ну и выложить данные, этому коду нужные максимально ровным и непрерывным слоем, но это просто). То есть сдуваем пыль со старой книжки про ассемблер.
Во-вторых, оптимизация нынче начинается со слова SIMD, и тут состояние имеющейся машинерии примерно как у Си-компиляторов в 1985 году, и если надо быстро - ручками, всё ручками. https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...

Ответить | Правка | Наверх | Cообщить модератору

15. "Для PostgreSQL представлена реализация условных индексов" +/–

Сообщение от Crazy Alex (ok), 26-Июн-15, 00:11

Получится так, как будет в инструкции к ORM. Да, с какого-то момента - звать DBA. Но если этот момент отодвинуть - это значит, что для определённого процента проектов он не наступит вообще никогда.
А в ассемблере - слабо представляю ручное раскидывание параметров и переменных по регистрам на сколько-нибудь большом объёме кода. SIMD - это там, где надо обрабатывать большие однородные массивы, а этого, как, ни странно, не так уж много. А где обычный код - с кучей веток исполнения, небольшими функциями, тремя-четырьмя уровнями индирекшна - там как раз компилятору раздолье, а людям делать нечего. О PGA и прочих JIT-оптимизациях я и не говорю. Когда начинается многопоточность со всеми memory barriers и прочим - тем более невелика радость.
По поводу ссылки - у игроделов все SIMD и ассемблеры закончатся ровно там, где начнётся AI. Не только потому, что его в половине случаев вообще на скриптах пишут, но и потому, что там обычно вагон условий и сравнительно мало молотилок чисел.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	5. "Для PostgreSQL представлена реализация условных индексов"	+/–
	Сообщение от Crazy Alex (ok), 25-Июн-15, 19:14
	Если есть возможность использовать машинно-реализуеамый костыль вместо мозгов - надо её использовать. Такой костыль может использоваться самой машиной, мозги - только в комплекте с живым человеком.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Для PostgreSQL представлена реализация условных индексов"	+2 +/–
	Сообщение от rob pike (?), 25-Июн-15, 21:46
	Ну так какой смысл-то в использовании этого конкретного костыля? Наплодить автоматически 100500 индексов, чтоб insert потом застрелился от безнадеги? Ладно бы опции CONCURRENTLY у CREATE INDEX не было, так ведь есть же. Нужен индекс - сделай. Не нужен - не сделай. Нужен, сделал, не используется планировщиком - подкрути статистику (http://www.depesz.com/2013/05/30/explaining-the-unexplainabl.../)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. "Для PostgreSQL представлена реализация условных индексов"	+/–
	Сообщение от Crazy Alex (ok), 25-Июн-15, 22:32
	Почему 100500? Наплодить столько, сколько позволено настройками. Например, для ORM - милое дело, пожалуй, будет. Супер-производительности, может, и не будет - но зато автоматом. Ну и вообще это правильное направление, примерно как компиляторы в своё время хуже, чем люди, ассемблерный код генерили, а теперь - человек в состоянии посостязаться только на небольших кусках, и далеко не всякий.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	13. "Для PostgreSQL представлена реализация условных индексов"	+/–
	Сообщение от rob pike (?), 25-Июн-15, 23:41
	Ну вот только для ORM разве что. Получится, правда, всё равно как всегда - ANALYZE никто делать не будет, статистику крутить не будет, половина индексов будут медленнее seqscan-а. Зато можно написать "наш ORM умеет ого-го, приходить в сознание с ним вообще необязательно". Потом всё равно звать DBA со стороны и платить $200 в час чтоб как-то заворочалось. С ассемблером всё осталось ровно так же, потому что замок эволюционирует не медленней ключа. Во-первых, современный Haswell - он уже сильно умнее Сишного компилятора во многих местах (если не сказать "во всех"), причём недетерминированность проявляется и в этом - то есть оптимизация превращается в угадайку - кто угадал насколько тупого кода ему надо в этом конкретном месте с этими конкретными данными, чтобы он сказал "ага! я знаю этот паттерн!" и оптимизировал, тот и молодец. Что в подавляющем большинстве случаев выражается в практичности подхода "всё что мы можем осмысленно сделать - это добиться того чтобы этот чанк кода помещался в кэш" (ну и выложить данные, этому коду нужные максимально ровным и непрерывным слоем, но это просто). То есть сдуваем пыль со старой книжки про ассемблер. Во-вторых, оптимизация нынче начинается со слова SIMD, и тут состояние имеющейся машинерии примерно как у Си-компиляторов в 1985 году, и если надо быстро - ручками, всё ручками. https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afr...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Для PostgreSQL представлена реализация условных индексов"	+/–
	Сообщение от Crazy Alex (ok), 26-Июн-15, 00:11
	Получится так, как будет в инструкции к ORM. Да, с какого-то момента - звать DBA. Но если этот момент отодвинуть - это значит, что для определённого процента проектов он не наступит вообще никогда. А в ассемблере - слабо представляю ручное раскидывание параметров и переменных по регистрам на сколько-нибудь большом объёме кода. SIMD - это там, где надо обрабатывать большие однородные массивы, а этого, как, ни странно, не так уж много. А где обычный код - с кучей веток исполнения, небольшими функциями, тремя-четырьмя уровнями индирекшна - там как раз компилятору раздолье, а людям делать нечего. О PGA и прочих JIT-оптимизациях я и не говорю. Когда начинается многопоточность со всеми memory barriers и прочим - тем более невелика радость. По поводу ссылки - у игроделов все SIMD и ассемблеры закончатся ровно там, где начнётся AI. Не только потому, что его в половине случаев вообще на скриптах пишут, но и потому, что там обычно вагон условий и сравнительно мало молотилок чисел.
	Ответить \| Правка \| Наверх \| Cообщить модератору