Спасибо большое за интересные статьи и что продолжаете, как обещали.
Часть теории конечно вполне тривиальна, но здорово что всё вместе и последовательно.
Я хотел спросить на счёт порядка определения своего класса операторов. Скажем в вашем примере, сначала для комплексных чисел используется дефолтный метод. Что если мы сначала создадим btree индекс по этому полю, а потом уже определим класс операторов:
create operator class complex_ops
Достаточно ли postgres «умный» чтобы не стать использовать для индексов, создававшихся с другими операторами вновь созданный?
И если мы хотим чтобы старый индекс стал использовать новый класс операторов, его обязательно пересоздавать? Или есть другие возможности перестроения (REINDEX)?
Не могли бы вы пожалуйста пояснить подробнее про хранение NULL и что нужно было увидеть с помощью Pageinspect?
Я пытаюсь разобрать приведённый вами пример:
CREATE TABLE t1(x int, y int);
CREATE TABLE t2(x int not null, y int not null);
INSERT INTO t1 VALUES (1, 1)
SELECT * FROM heap_page_items(get_raw_page('t1', 0)) limit 1;
В особенности если это используется для тестирования, рекомендую просто подготовить Docker образ, и откатываться к любой закоммиченной точке в течении единичных секунд.
Задача, в том числе, максимально упростить вход разработчика в приложение, чтобы все инструкции по сборке и запуску приложения, от многодневных попыток, как это было еще с год назад, сводились к:
git clone …
./gradlew dockerRun
При этом бы приложение бы сразу запустилось, но не с игрушечной базой (как обычно делают вроде in-memory H2 для тестов с парой записей), а с базой, на которой, в том числе гоняются интеграционные и перфоманс тесты на CI и чтобы воспроизвести можно было 99.9% проблем из продакшена.
Более того, я для простоты этот шаг убрал, чтобы не засорять описание, но имея стабильную master ветку, я ещё прогоняю все имеющиеся там миграции на БД (c помощью flyway) в момент билда — так, чтобы эта база запускалась бы моментально.
У CitusDB нет более-менее эффективных произвольных JOIN'ов. Хотят видеть только JOIN по одинаковым распределённым ключам.
Простите, что значит нет?
Ещё с версии 4.х эквиджойны есть для любых таблиц:
CitusDB supports equi-JOINs between any number of tables irrespective of their size and distribution method. The query planner chooses the optimal join method and join order based on the statistics gathered from the distributed tables. It evaluates several possible join orders and creates a join plan which requires minimum data to be transferred across network.
Или вы имеете ввиду что работают они медленно и оптимизатор плохо справляется с локальностью данных?
Да, прошу прощения, но всё-таки очень хочется спросить ещё про In-Memory-Data-Grid, или In-Memory-SQL-Grid. Вы их рассматривали? В частности, например проект apache ignite предоставляет не только программный интерфейс в стиле Data Grid computing, но обещают прямо ANSI SQL-99 совместимость и стандартный JDBC доступ.
Очень интересно ваше мнение по этому поводу.
Даже наличие опциональной поддержки inmemory как отменяет использование индексов?? Причём как в памяти, так и для оставшейся на диске части? Некоторые базы, вроде Exasol, вообще делают их автоматически в памяти, как рассказывал tinkoff, большинству же остальных так или иначе они всё равно нужны от DBA.
Обученная модель в переменной model.
Если вам прислали картинку которую вы хотите классифицировать, в общем случае вам нужно привести её в тот же вид (сначала размерность и цветность 28*28 grayscale, затем в одномерный вектор, как в начале статьи). Затем, в простейшем случае вы можете просто вызвать метод predict.
Для сохранения модели, чтобы не тратить лишний раз время на тренировку, имеются различные методы записи на диск и экспорта в JSON или YAML — https://keras.io/models/about-keras-models/
Базовые индексы и механизмы у вас очень хорошо рассказаны в DBA2 курсе. А вот про «новые», Бартунов и Коротков постоянно рассказывают на конференциях, прямо как затравки. Каждый раз думаешь «вау, как круто», но так чтобы понять, а главное приспособить в реальной жизни что-то кроме Btree или Gin даже и не понятно с какой стороны смотреть толком…
3 Мб оверхеда, да ещё и выковырянных из другого проекта. Вы же, как я понял, всё равно используете maven-указаение зависимостей и его артефакты. Ivy (https://mvnrepository.com/artifact/org.apache.ivy/ivy/2.4.0) занимает всего 900Кб и готов к использованию. В том числе как зависимость проекта, в котором вы собираете единый артефакт.
На сколько я понимаю, основной смысл использование в скриптах, эта же тема развивается в комментариях, что сложных случаев каких-то зависимостей не нужно. Так зачем тогда на столько усложнять и увеличивать объём артефакта более чем в 3 раза?
Часть теории конечно вполне тривиальна, но здорово что всё вместе и последовательно.
Я хотел спросить на счёт порядка определения своего класса операторов. Скажем в вашем примере, сначала для комплексных чисел используется дефолтный метод. Что если мы сначала создадим btree индекс по этому полю, а потом уже определим класс операторов:
Достаточно ли postgres «умный» чтобы не стать использовать для индексов, создававшихся с другими операторами вновь созданный?
И если мы хотим чтобы старый индекс стал использовать новый класс операторов, его обязательно пересоздавать? Или есть другие возможности перестроения (REINDEX)?
Я пытаюсь разобрать приведённый вами пример:
Вывод:
Вывод:
Абсолютно одинаковые.
Пробую вставит null значения:
И всё равно всё то же самое.
На каком основании сделать какая из них занимает меньше места?
P.S. Форматированный вывод, который выроятно будет удобнее смотреть: paste.fedoraproject.org/paste/z50hMUVlKZ4Idh0mgqTEBQ
ERROR: block number 0 is out of range for relation «t1»
Вероятно стоит добавить что для этого требуется в таблицу вставить хотя бы один кортеж.
При этом бы приложение бы сразу запустилось, но не с игрушечной базой (как обычно делают вроде in-memory H2 для тестов с парой записей), а с базой, на которой, в том числе гоняются интеграционные и перфоманс тесты на CI и чтобы воспроизвести можно было 99.9% проблем из продакшена.
Более того, я для простоты этот шаг убрал, чтобы не засорять описание, но имея стабильную master ветку, я ещё прогоняю все имеющиеся там миграции на БД (c помощью flyway) в момент билда — так, чтобы эта база запускалась бы моментально.
Простите, что значит нет?
Ещё с версии 4.х эквиджойны есть для любых таблиц:
Или вы имеете ввиду что работают они медленно и оптимизатор плохо справляется с локальностью данных?
Очень интересно ваше мнение по этому поводу.
Если вам прислали картинку которую вы хотите классифицировать, в общем случае вам нужно привести её в тот же вид (сначала размерность и цветность 28*28 grayscale, затем в одномерный вектор, как в начале статьи). Затем, в простейшем случае вы можете просто вызвать метод predict.
Для сохранения модели, чтобы не тратить лишний раз время на тренировку, имеются различные методы записи на диск и экспорта в JSON или YAML — https://keras.io/models/about-keras-models/
А почему не тестировались CitusDB (в отличие от GreenPlum ставится поверх Postgres, то есть работает на свежих версиях, а не 8.4) и monetdb?
А когда ждать продолжение про RUM и VODKA?
На сколько я понимаю, основной смысл использование в скриптах, эта же тема развивается в комментариях, что сложных случаев каких-то зависимостей не нужно. Так зачем тогда на столько усложнять и увеличивать объём артефакта более чем в 3 раза?