Всем привет)

кто нибудь юзал brin индексы?

запилить бы еще пейдж индексы)

магия! :)

))

это не магия, это постгрес )

???

кто нибудь юзал brin индексы?

Да, крутая штука. Если данные типо временного ряда, то можно сделать таблицу без primary key, но с brin, и на сотни гигов данных иметь индекс около мегабайта, быстрая вставка, быстро работаю range запросы

Я правильно понимаю, что brin - это реализация bloom filter?

О, спасибо парни!

разве на brim range будет быстрее, чем на btree?

там вроде вставка и размер только плюсы

разве на brim range будет быстрее, чем на btree?

запросы быстро делать и там и там, но btree может сам весить как таблица

brin медленее должен быть на поиск. не понимаю за счёт чего он должен быть быстрее

ага, вот статья есть: http://postgresmen.ru/articles/postgresql-9.5-alpha - пример поиска: $ select count(*) from table where id between 600000::int8 and 650000::int8; * btree between: 9.574 ms * brin between: 21.090 ms

Я правильно понимаю, что brin - это реализация bloom filter?

Нет, brin ведет min/max для страниц и работает если есть корреляция между данными и номером страницы. Когда пишут timeseries это как раз такой случай.

Ага, спасибо

brin медленее должен быть на поиск. не понимаю за счёт чего он должен быть быстрее

Я не имел в виду, что он быстрее. Я про то что приемлемо быстро на очень больших данных и почти без накладных расходов. Но и быстрее он тоже может быть — просто пример если btree такой жирный, что не влез в shared buffers (на таблицах в пару террабайт — запросто)

Благодарю)

Привет!

Сижу на митапе fprog в Питере. Тут автор доклада упомянул свой pet-проект: UI к postgres на clojurescript https://github.com/niquola/ankus

Там всякие диаграммы можно сразу смотреть, графы foreign keys

> Requirements

господи исусе

господи исусе

В контейнер всё запихнуть. Делов-то.

ну не все еще знают ) не все

Сижу на митапе fprog в Питере. Тут автор доклада упомянул свой pet-проект: UI к postgres на clojurescript https://github.com/niquola/ankus

А issue №7 в трекере этого проекта написал я

И придумал issue №8

Но оно на epic тянет

Его сперва описать нормально надо

Платиновые треды гитхаба

https://github.com/ashrithr/ankus/issues/38

я б даже попробовал

https://github.com/ashrithr/ankus/issues/38

А это не тот ankus!

на тянуть все эти штуки ?

Надо Коле сказать - пусть имя меняет

черт.

Лишняя k

так лучше https://github.com/niquola/ankus/issues/8 ?

Дя

Но зачем?

Ну может сделаем визуализацию performance метрик как в Oracle сделано

Там вообще все четко

Хочу в Pg такое же

Да, хотя бы дблинк и автономные

А дальше больше

а что не так с текущими dblink и fdw_postgres?

Ну они другие?

Работать можно

Но не так удобно

@niquola тебя нахваливают тут, приди!

Он не увидит, если его в группе нет

по поводу Oracle dblink. Может оно и удобно, но сказать честно, за мои более чем 10 лет плотнейшей работы с Oracle, я не видел, чтоб dblink функционал использовался как некая основа в построении решения. Максимум это сами админя для себя что-то мутили

ну а в pgsql за небольшой период чего только не довелось перепробовать

может от того, что я сам стал проектировать решения...

zfs пригодна для чего-то кроме как поставить её на домашней машине и улыбаться сидеть?

Расскажи об этом солнечным.... посмеются

Расскажи об этом солнечным.... посмеются

так нет тех солнечных. Только оракл и остался

ZFS прекрасна. НО - на Solaris

я тут пытался воспользоваться ZFS на Debian stable и очень об этом пожалел

Системы то есть..... SmartOS например..... бсд отлично работает на zfs

BSD не смотрел. SmartOS -> Solaris

как и OpenSolaris

Поддержки нет на опенсол

Поддержки нет на опенсол

в смысле техпо? Так ее и на FreeBSD вроде не особо. Нужна техпо - вам к сейлзам оракл

ZFS не торт как минимум из-за своих проблем с лицензией.

Иначе бы может быть и был толк... а так без нормальной реализации и open source коммьюнити толку мало.

Кроме того эта концепция крайне сложная, даже вон HP с BTRFS осилить не могут.

Проект не развивается давно...... сейлзы оракла это дорого и бессмыслено

Ну и скорость + мультипоточная скорость там крайне низкая.

Файловая система вообще вещь сложная. Исторически. ZFS - попытка прыгнуть выше головы. Которая, ммм... Не совсем удалась

ext4 наше всё.

надежность

то же самое про Project Crossbow, если кто его вообще помнит

фат32

Наше все

надежность

не в linux, увы. Модуль глючный, портит ФС

фат32

JFFS

не в linux, увы. Модуль глючный, портит ФС

Согласен. Хотя если задуматься генту?

Согласен. Хотя если задуматься генту?

он везде одинаковый, ZFS On Linux. Пока что он крайне сырой и его нельзя называть более, чем бетой

увы

хотя авторы очень стараются

Файловая система вообще вещь сложная. Исторически. ZFS - попытка прыгнуть выше головы. Которая, ммм... Не совсем удалась

Я бы не стал рассматривать zfs только в среде линукса

а я сейчас не про линукс говорил

ZFS в принципе очень концептуально сложная вещь

Ну главное втянуться

в написание файлсистем? Нет, спасибо