А куда ему родному деваться-то? Так реляционная алгебра постулирует.
Тут даже более приземленно - для планировщика это одно из отношений (с типом VALUES) и он ничего не знает о его содержимом, так как его окончательное содержимое выдаст экзекьютор, выполнив этот узел.
Пока parser отдельно не выделяет константные VALUES (без условий, сортировок и LIMIT), планировщик ничего не сможет сделать
А не может быть причиной то, что VALUES были в SQL всегда, а массивы появились в PostgreSQL значительно позднее? Традиционно PostgreSQL считает, что VALUES - это один из видов отношений, и обрабатывает его сразу, как отношение. IN ( rowset) на раннем этапе планирования преобразовывается в JOIN, и после этого момента константный VALUES поздно оптимизировать (функции и константные выражения обрабатываются позднее). Думаю, разумнее, чтобы такие вещи делал все-таки сервер, а не программисту DB разбираться в особенностях планировщика - у программиста DB своих проблем на своем уровне хватает.
При создании модели планировщика можно учитывать текущую нагрузку сервера, как параметр? Например, при высокой нагрузке будут строится планы с учетом этой нагрузки (например, без parallel workers, так как они сейчас все заняты, или меньше памяти под какой-то вариант плана - это уже модель сама решит, что поменять). Чтобы модель не только умно планы создавала, но умно реагировала на нагрузку сервера
Может быть об этом надо дополнительно сказать в документации к IN. Тем более, что оба оператора IN описываются в двух разных разделах. Пока на грабли не наступят, не обратят на это внимание. Как из вопросов про английский:"Иногда вижу has, иногда had - никак не пойму разницу, почему буква на конце разная"
Интересно, что пользователи используют такую конструкцию IN (VALUES(1),(2)...) и видят замедление запроса, и пытаются это понять, но это им не очевидно. Это из реальных вопросов программистов. То, что IN - это два разных оператора в случае массива справа и набора данных из одного поля справа - это не очевидно. Соответственно, не очевидно, что надо запрос переделать на более оптимальный.
Вы написали "Хотя она (PostgreSQL) и позволяет размещать большие базы с высокой транзакционной или аналитической нагрузкой как монолитные системы, они работают медленнее, чем хотелось бы, упираясь в производительность железа." Не могли бы Вы сослаться хотя бы на один источник информации, откуда следует, что Postgres работает медленнее (по контексту - Oracle). Oracle юридически запрещает все бенчмарки. Вы видели какие-то сравнения по скорости? Хотел тоже посмотреть.
Векторными называют базы, в которых есть функция поиска (быстрого поиска) векторов (вектор - длинный массив чисел, хранить могут почти все базы, но быстро искать - почти никто). Чтобы точно найти ближайший вектор, надо полностью перебрать всю базу (это математическая теорема), поэтому используют приблизительный поиск. Обычно - чем меньше точность поиска, тем больше скорость и наоборот. Точность можно измерить на тестовых наборах данных или в своем приложении - при разных параметрах Вы просто видите, что поиск начал выдавать какую-то ерунду и увеличиваете точность поиска параметрами.
Скажите, а почему Вы задаетесь таким вопросом? Вы же не видели лицензионного соглашения на тот ключ, и не можете рассуждать без него о правомерности использования ключа. Вы не собственник лицензии, но Вас почему-то беспокоит, что кто-то кому-то переслал ключ от чужой программы. Не первый раз вижу подобные заявления, и не понимаю их смысла.
Если не секрет, что за работа, на которой приходилось заниматься векторами? Просто интересно, кто уже реально этой технологией пользовался для работы, а не для тестирования.
Не отрицая разумности изложенных правил рынка труда, хочу обратить внимание на факты, обсуждение которых сейчас избегают, так как это тема хуже Холокоста евреев с 6 миллионами погибших, а виновники живы до сих пор: в России в 90-е годы вместо 20-25 миллионов родилось около 10 миллионов детей. 10 миллионов просто не родилось, а они сейчас должны были пойти на работу, менять тех, кто уходит на пенсию. Плюс к этому увеличение смертности в полтора раза. Теперь каждые 30 лет будет волна спада рождаемости. Это и есть причина дефицита, просто нет людей. И это никак не компенсировалось мигрантами.
Только надо привязать в одном из тех шести прямоугольников, так как наружи неисправные поезда не поедут, и до 21 ноября, иначе они из-за "неисправного" компрессора тоже не выйдут на маршрут.
Я не вполне понял, почему Вы себя называете мы. Вы нигде не представлялись, как коллектив авторов.
Вы уже видите, что Ваша статья не привлекла никакого внимания пользователей. Здесь начинается дискуссия по любому мало мальски стоящему поводу. Уже можете написать своим кураторам, чтобы переводили серебренники за проделанную работу.
На тот редкий и невероятный случай, что Вы действительно решили для себя проделать эту работу, то только в этом случае хотел Вам сказать, что Вы не туда полезли, и прямо нарушаете законодательство страны. Не удивляйтесь, это стандартная практика всех стран, запрещающих вмешиваться в выборы. Можете удивиться и написать статью про результаты выборов в штате Мичиган в 2020 году. И тогда мы с Вам увидимся лет через 18, если Вы попытаетесь это опубликовать где-то в района штата Мичиган.
И что Вам дает дата моей регистрации и количество комментариев? Регистрируюсь, когда хочу, комментирую, когда хочу. Мне есть чем заняться. Я свою первую программу написал в 1986 году. Для я меня этот ресурс - место чтения информации. А не просмотра вот таких политических высевов, которым не место на IT сайте.
Для тех, кто в серьез принимает статьи с анализом фальсификации выборов, сообщу такую информацию. Благодаря развитию технологий появилось много онлайн игр, да и традиционные игры типа шахмат ушли в онлайн формат. И неожиданно оказалось, что во многих играх, даже в шахматах, проявляются те же аномалии, которые борцы с фальсификациями считают подтасовками на выборах. Распределения рейтингов, результаты в турнирах соответствуют не нормальному гауссовому распределению, а дают аномальные пики на значениях кратным 100 и т.п. аномалии. Люди почему-то не ведут себя, как шары в вакууме. В связи с этим возникает вопрос - а в странах с многолетней демократией и (многолетним опытом фальсификаций) почему анализ дает такие гладкие гауссовые кривые? Может быть там фальсификация?
Я считаю, что такие статьи (чем более от анонимных новорегов) - это попытка вмешаться в выборы в описываемой стране. И , по большому счету, таким статьям не место на habr-е.
Урезанность функционала заключается в том, что изменения не сохраняются, а формулы в режиме только для чтения. Редактор, который не редактирует, электронная таблица, которая не считает.
Тут даже более приземленно - для планировщика это одно из отношений (с типом VALUES) и он ничего не знает о его содержимом, так как его окончательное содержимое выдаст экзекьютор, выполнив этот узел.
Пока parser отдельно не выделяет константные VALUES (без условий, сортировок и LIMIT), планировщик ничего не сможет сделать
А не может быть причиной то, что VALUES были в SQL всегда, а массивы появились в PostgreSQL значительно позднее? Традиционно PostgreSQL считает, что VALUES - это один из видов отношений, и обрабатывает его сразу, как отношение. IN ( rowset) на раннем этапе планирования преобразовывается в JOIN, и после этого момента константный VALUES поздно оптимизировать (функции и константные выражения обрабатываются позднее). Думаю, разумнее, чтобы такие вещи делал все-таки сервер, а не программисту DB разбираться в особенностях планировщика - у программиста DB своих проблем на своем уровне хватает.
При создании модели планировщика можно учитывать текущую нагрузку сервера, как параметр? Например, при высокой нагрузке будут строится планы с учетом этой нагрузки (например, без parallel workers, так как они сейчас все заняты, или меньше памяти под какой-то вариант плана - это уже модель сама решит, что поменять). Чтобы модель не только умно планы создавала, но умно реагировала на нагрузку сервера
Может быть об этом надо дополнительно сказать в документации к IN. Тем более, что оба оператора IN описываются в двух разных разделах. Пока на грабли не наступят, не обратят на это внимание. Как из вопросов про английский:"Иногда вижу has, иногда had - никак не пойму разницу, почему буква на конце разная"
Интересно, что пользователи используют такую конструкцию IN (VALUES(1),(2)...) и видят замедление запроса, и пытаются это понять, но это им не очевидно. Это из реальных вопросов программистов. То, что IN - это два разных оператора в случае массива справа и набора данных из одного поля справа - это не очевидно. Соответственно, не очевидно, что надо запрос переделать на более оптимальный.
Спасибо! Прочитал и вдохновился.
Добрый день!
Вы написали "Хотя она (PostgreSQL) и позволяет размещать большие базы с высокой транзакционной или аналитической нагрузкой как монолитные системы, они работают медленнее, чем хотелось бы, упираясь в производительность железа." Не могли бы Вы сослаться хотя бы на один источник информации, откуда следует, что Postgres работает медленнее (по контексту - Oracle). Oracle юридически запрещает все бенчмарки. Вы видели какие-то сравнения по скорости? Хотел тоже посмотреть.
Векторными называют базы, в которых есть функция поиска (быстрого поиска) векторов (вектор - длинный массив чисел, хранить могут почти все базы, но быстро искать - почти никто). Чтобы точно найти ближайший вектор, надо полностью перебрать всю базу (это математическая теорема), поэтому используют приблизительный поиск. Обычно - чем меньше точность поиска, тем больше скорость и наоборот. Точность можно измерить на тестовых наборах данных или в своем приложении - при разных параметрах Вы просто видите, что поиск начал выдавать какую-то ерунду и увеличиваете точность поиска параметрами.
>Но будет ли такая инсталляция лицензионной?
Скажите, а почему Вы задаетесь таким вопросом? Вы же не видели лицензионного соглашения на тот ключ, и не можете рассуждать без него о правомерности использования ключа. Вы не собственник лицензии, но Вас почему-то беспокоит, что кто-то кому-то переслал ключ от чужой программы. Не первый раз вижу подобные заявления, и не понимаю их смысла.
Если не секрет, что за работа, на которой приходилось заниматься векторами? Просто интересно, кто уже реально этой технологией пользовался для работы, а не для тестирования.
У меня сейчас повился Макбук про с функциональными кнопками вместо тачбара, и я счастлив после 5 лет мучения. Вот уж о вкусах не спорят.
Не отрицая разумности изложенных правил рынка труда, хочу обратить внимание на факты, обсуждение которых сейчас избегают, так как это тема хуже Холокоста евреев с 6 миллионами погибших, а виновники живы до сих пор: в России в 90-е годы вместо 20-25 миллионов родилось около 10 миллионов детей. 10 миллионов просто не родилось, а они сейчас должны были пойти на работу, менять тех, кто уходит на пенсию. Плюс к этому увеличение смертности в полтора раза. Теперь каждые 30 лет будет волна спада рождаемости. Это и есть причина дефицита, просто нет людей. И это никак не компенсировалось мигрантами.
Только надо привязать в одном из тех шести прямоугольников, так как наружи неисправные поезда не поедут, и до 21 ноября, иначе они из-за "неисправного" компрессора тоже не выйдут на маршрут.
Я не вполне понял, почему Вы себя называете мы. Вы нигде не представлялись, как коллектив авторов.
Вы уже видите, что Ваша статья не привлекла никакого внимания пользователей. Здесь начинается дискуссия по любому мало мальски стоящему поводу. Уже можете написать своим кураторам, чтобы переводили серебренники за проделанную работу.
На тот редкий и невероятный случай, что Вы действительно решили для себя проделать эту работу, то только в этом случае хотел Вам сказать, что Вы не туда полезли, и прямо нарушаете законодательство страны. Не удивляйтесь, это стандартная практика всех стран, запрещающих вмешиваться в выборы. Можете удивиться и написать статью про результаты выборов в штате Мичиган в 2020 году. И тогда мы с Вам увидимся лет через 18, если Вы попытаетесь это опубликовать где-то в района штата Мичиган.
И что Вам дает дата моей регистрации и количество комментариев? Регистрируюсь, когда хочу, комментирую, когда хочу. Мне есть чем заняться. Я свою первую программу написал в 1986 году. Для я меня этот ресурс - место чтения информации. А не просмотра вот таких политических высевов, которым не место на IT сайте.
Для тех, кто в серьез принимает статьи с анализом фальсификации выборов, сообщу такую информацию. Благодаря развитию технологий появилось много онлайн игр, да и традиционные игры типа шахмат ушли в онлайн формат. И неожиданно оказалось, что во многих играх, даже в шахматах, проявляются те же аномалии, которые борцы с фальсификациями считают подтасовками на выборах. Распределения рейтингов, результаты в турнирах соответствуют не нормальному гауссовому распределению, а дают аномальные пики на значениях кратным 100 и т.п. аномалии. Люди почему-то не ведут себя, как шары в вакууме. В связи с этим возникает вопрос - а в странах с многолетней демократией и (многолетним опытом фальсификаций) почему анализ дает такие гладкие гауссовые кривые? Может быть там фальсификация?
Я считаю, что такие статьи (чем более от анонимных новорегов) - это попытка вмешаться в выборы в описываемой стране. И , по большому счету, таким статьям не место на habr-е.
Урезанность функционала заключается в том, что изменения не сохраняются, а формулы в режиме только для чтения. Редактор, который не редактирует, электронная таблица, которая не считает.