Давайте не будем об этом зарание :)
Я прекрасно понимаю о чём речь. Правда корень нашего с вами недопонимания в том, что я говорю про стандарт SQL в котором хинтов нету, ну и к примеру Postgres где их то же принципиально нету.
SQL увы часто слишком высокоуровневый и трудный для оптимизации язык.
Он никак не описывает взаимодействие с индексами или какой алгоритм джойна или выборки использовать. В общих случаях и небольших нагрузках всё может быть хорошо, но дальше начинаются танцы с бубном над оптимизатором. Да и для многих случаев разбор и оптимизация занимает больше времени чем сама выборка данных.
Ну и сам по себе SQL не очень знаком с транзакциями и изоляциями.
Все функции PG_FUNCTION_INFO_V1 автоматически маркируются атрибутом DLLEXPORT на Windows (Laurenz Albe). Если сторонний код использует декларацию extern функции, он так же должен использовать отметку DLLEXPORT для таких деклараций.
Наконец мои стекнания косвенно но привели к результату. Правда я всё ещё хотел бы видеть контриб модули как "плагины" и внятный API со стороны постгреса.
спрашивает, если надо что то открыть не в своей локальной песочнице и к примеру на внешней флешки то нужны пермишены.
Тольуо увы у Android сейчас 3 разные системы для открытия файлов не из родной директории. :( Это куча костылей для каждой версии андроида.
Всё зависит от того кем вы были до этого. Минимальные ставки тут высокие и если вы уходили с 80тр в месяц то тут будуете получать 130-150. Да конечно тут и расходов больше, особенно проезд но зато и уровень жизни выше. А так в целом сюда не за деньгами едут… хотя при желании и времении и их поднять можно.
Нет, тут всё в целом как в РФ даже местами по проще. Конторы в которых народ без остановки работает ещё конечно есть НО:
их всё меньше меньше
поменяли тут трудовое законодательство и теперь их пресуют, а за смерть на рабочем месте вообще АДъ делают. (мы обязательно отмечаемся сколько мы были на рабочем месте каждый день, и этот табель отдают в трудовую инспекцию каждый месяц)
Синдзе Абе по сути сделал национальной идеей работать меньше, делать больше. В итоге мой друг, который устроился в классическую Японскую контору (он там единственный гайдзин на >3000 человек) в итоге "халявит", в смысле всё нормально и даже слишком "мало работы".
Короче для ИТ это сейчас редкость, особенно там где примут на работу гайдзина. В остальных сферах становится лучше… НО лучше иногда совсем на чуть чуть. Повара тут вкалывают огого.
Как хорошо, что я в итоге в Японию уехал, тут особо русских компаний нету. :)
О да тут свой зоопарк и жесткач бывает НО я благо его обошёл.
Ну и ещё один плюс — сюда без доков приехать нельзя для гражданина РФ (сертификат COE могут дать только в посольстве в Москве), а уже в японии всегда есть 3 месяца после увольнения что бы найти новую работу.
Нет, мешает протокол. Нельзя открыть курсор, делать из него фетч и на (допустим) каждую строку выполнять выполнять еще один запрос в этом же соединении. Посмотрите протокол постгреса.
протокол строго однопоточный… а курсор это часть единого pipline который разорвать нельзя :(
У постгреса в принципе плохо с обвязом вокруг самой БД. Отчасти это потому, что на Си писать такое тяжко.
А что то ещё внедрять или придумывать нехватает решимости у коммьюнити.
Судя по профилю их нагрузки, им нужен был redis + что то для логов. (это если брать именно обновление позиции машины и статуса заказа) Им просто в большей части нагрузки MVCC нафиг не упёрся.
Да, проблеммы у Postgres есть, и Uber наткнулся только на маленькую часть. Но конкретно их проблемму вполне можно было бы сильно уменьшить если общаться с сообществом. (уже сейчас улучшения есть)
Но главная проблемма Postrges которую никто не пытается исправить это дизайн >20 летней давности. Postgres развивается небольшими шажками без серьёзных рефакторингов из-за этого, код это ужасная лапша и архитектура сильно устарела, а у сообщество не может и не хочет что то менять. Отчасти из-за архитектуры и языка Си, развите postrges сейчас крайне сложное дело. Архитектурные пробелы это процессы, а не потоки и самопальный буфер менеджер вместо iommap. Не говоря уже про организацию tuple. На данный момент в аналитических запроссах большая часть времени уходит на процесс разбора тюплов. heap (сторадж данных) прибит гвоздями, индексы отваязаны но с ограничениями.
Простите за этот сумбур, я думаю тут надо писать целую статью, но общий вывод в том что postgres распространяется под BSD лицензией и его развитие это мягко говоря политическая игра между несколькими игроками… из-за этого реально нужные вещи просто не делаются.
PS но при этом, это хорошая СУБД и наверное одна из самых лучших, особенно что касается фичь SQL и расширябельности. Только вот насколько долго она такой останется?
Вы не поняли моего мессаджа. React и собраться сделаны для реализации веб приложений и в этом случае наверное от их аналогов никуда не деться, но сейчас на них начинают клепать сайты которые великолепно бы легли на шаблоны сервера и работали бы мега быстро даже с полным обновлением страницы.
ЗЫ а для решения "layout trashing" надо больше css юзать, а не через JS всё проставлять.
Если не использовать все эти новомодные JS фреймворки то скорость и так выше некуда.
Мне кажется мы сами себе придумали проблему, а теперь героически её решаем.
Давайте не будем об этом зарание :)
Я прекрасно понимаю о чём речь. Правда корень нашего с вами недопонимания в том, что я говорю про стандарт SQL в котором хинтов нету, ну и к примеру Postgres где их то же принципиально нету.
SQL увы часто слишком высокоуровневый и трудный для оптимизации язык.
Он никак не описывает взаимодействие с индексами или какой алгоритм джойна или выборки использовать. В общих случаях и небольших нагрузках всё может быть хорошо, но дальше начинаются танцы с бубном над оптимизатором. Да и для многих случаев разбор и оптимизация занимает больше времени чем сама выборка данных.
Ну и сам по себе SQL не очень знаком с транзакциями и изоляциями.
Поменяли бы только реализацию… сегодня это АДъ из-за которого чаще всего и тормозит 1С (а точнее не использует UUID).
Наконец мои стекнания косвенно но привели к результату. Правда я всё ещё хотел бы видеть контриб модули как "плагины" и внятный API со стороны постгреса.
Если кто хочет собирать новый постгрес при помощи CMake и возможно Ninja то вы можете попробвать эту ветку:
https://github.com/stalkerg/postgres_cmake/tree/cmake_rel10
или патч
https://gist.github.com/stalkerg/9da894195628d24b3cf25f399af3714e
Там же вы найдёте как можно собрать постгрес под Windows без захода в консоль вообще.
спрашивает, если надо что то открыть не в своей локальной песочнице и к примеру на внешней флешки то нужны пермишены.
Тольуо увы у Android сейчас 3 разные системы для открытия файлов не из родной директории. :( Это куча костылей для каждой версии андроида.
Когда хабр, сделает пагинацию для комментов? У меня комп виснет на этой странице.
Всё зависит от того кем вы были до этого. Минимальные ставки тут высокие и если вы уходили с 80тр в месяц то тут будуете получать 130-150. Да конечно тут и расходов больше, особенно проезд но зато и уровень жизни выше. А так в целом сюда не за деньгами едут… хотя при желании и времении и их поднять можно.
Нет, тут всё в целом как в РФ даже местами по проще. Конторы в которых народ без остановки работает ещё конечно есть НО:
Короче для ИТ это сейчас редкость, особенно там где примут на работу гайдзина. В остальных сферах становится лучше… НО лучше иногда совсем на чуть чуть. Повара тут вкалывают огого.
Да я хочу пост написать, пока что то руки не доходят. :) Но я обязательно это сделаю.
Как хорошо, что я в итоге в Японию уехал, тут особо русских компаний нету. :)
О да тут свой зоопарк и жесткач бывает НО я благо его обошёл.
Ну и ещё один плюс — сюда без доков приехать нельзя для гражданина РФ (сертификат COE могут дать только в посольстве в Москве), а уже в японии всегда есть 3 месяца после увольнения что бы найти новую работу.
протокол строго однопоточный… а курсор это часть единого pipline который разорвать нельзя :(
У постгреса в принципе плохо с обвязом вокруг самой БД. Отчасти это потому, что на Си писать такое тяжко.
А что то ещё внедрять или придумывать нехватает решимости у коммьюнити.
Не, если ждать то ничего не будет, надо в хакерс написать предложение и usecase. Без этого, процесс вообще не пойдёт.
Судя по профилю их нагрузки, им нужен был redis + что то для логов. (это если брать именно обновление позиции машины и статуса заказа) Им просто в большей части нагрузки MVCC нафиг не упёрся.
Старая тема но соображения такие:
Простите за этот сумбур, я думаю тут надо писать целую статью, но общий вывод в том что postgres распространяется под BSD лицензией и его развитие это мягко говоря политическая игра между несколькими игроками… из-за этого реально нужные вещи просто не делаются.
PS но при этом, это хорошая СУБД и наверное одна из самых лучших, особенно что касается фичь SQL и расширябельности. Только вот насколько долго она такой останется?
Вы не поняли моего мессаджа. React и собраться сделаны для реализации веб приложений и в этом случае наверное от их аналогов никуда не деться, но сейчас на них начинают клепать сайты которые великолепно бы легли на шаблоны сервера и работали бы мега быстро даже с полным обновлением страницы.
ЗЫ а для решения "layout trashing" надо больше css юзать, а не через JS всё проставлять.
Если не использовать все эти новомодные JS фреймворки то скорость и так выше некуда.
Мне кажется мы сами себе придумали проблему, а теперь героически её решаем.
Дык это только Си а у них есть поддержка C++.
Закупили списанное оборудование AMD.