А если так? SELECT * FROM pg_extension

ох, нехило так постгис в extcondition вывалил

То есть просто экстеншнов 3, а вот если смотреть в списке доступных,

Хотя нет. Идентично. Смутило Bollean поле :), а это оказываетя переносимость в другую схему :)

ох, нехило так постгис в extcondition вывалил

в качестве упражнения хотел было соединить всё это в одну строку, но оказалось не так всё просто

Привет всем, а у кого-нибудь в проектах есть Postgres с таблицами от 3 миллиардов записей?

3991181109 подойдёт?

3991181109 подойдёт?

?????

там ещё рядом табличка лежит, в которую один юзер вставил 326511847 строк

3991181109 подойдёт?

Нормас :) скажи, как постгрес справляется с таблицами таких размеров ? Есть ли у тебя индексы на ней дополнительные и долго ли происходит вставка ?

оно не у меня, оно на api.openstreetmap.org

там есть индексы по id, и кастомный не-постгисовый по геометрии

всё работает нормально

всё работает нормально

Я просто думаю как лучше сделать, одну большую таблицу или n маленьких таблиц и на вставку поставить триггер

партиционирований и тому подобного нет

триггер точно всё притормозит

Да но и индекс при вставке тоже отожрет в большую таблу

Да но и индекс при вставке тоже отожрет в большую таблу

А ты чаще читаешь или пишешь?

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

А ты чаще читаешь или пишешь?

Чаще читаю, но операций вставки полно

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

Потому что партицирование берёт только те кусочки, которые попадают в рендж?

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

https://github.com/postgrespro/pg_pathman

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

А по твоему опыту триггеры как?

если идёт аппенд, то непонятно, чем партиции будут лучше

А по твоему опыту триггеры как?

Настроил и забыл. Это иногда доставляло проблемы, но скорее после того как окунался в код после перерыва. А так в целом удобно.

если идёт аппенд, то непонятно, чем партиции будут лучше

Я думаю у него там всякие удаления ещё и прочее. Вакуум по кучке маленьких таблиц разве не лучше, чам по одной большой?

партиции удобны, когда нужно внезапно резко стереть чанк данных в размере партиции

Удалений скорее всего нет, но есть апдейты частые

Но это ещё не самые мощные таблицы, рядом будет стоять кликхаус в котором по триллиону записей в табле

Но там совсем другая история

Чувствую, я как всегда спроектирую и все развалится :)

там ещё рядом табличка лежит, в которую один юзер вставил 326511847 строк

Расскажи

@Komzpa @pasha_golub #report #spam

@Komzpa @pasha_golub #report #spam

Де? ?

Давно ее прибили. Я лично

Айфонопроблемы значит

Привет, подскажите, как можно сделать update from select нескольких полей, для каждого поля при этом в select должен быть свой where. Такое вообще возможно?

Пример: есть update за месяц, год и всё время (это и есть where) И есть поля с мес., годом и всем временем.

несколько апдейтов

А если одним?

Несколько уже есть.

Сказали, мол, можно одним

Несколько селектов. Подзапросы

Спасибо, попробую.

Расскажи

http://www.openstreetmap.org/stats/data_stats.html

http://www.openstreetmap.org/stats/data_stats.html

А, ну это же не за один раз

Но тоже впечатляет конечно

он раз в минуту отсылает в zabbix разницу между локальным временем и временем в последнем wal-сегменте пришедшего с другого сервера

Ой! дорогой ты мой человек!!! чего ж я в субботу то это не увидел спасибо тебе, а я уже маляву накатал https://www.facebook.com/groups/postgresql/permalink/627585317438219/ сидел разбирался сегодня три часа с исходниками mamonsu...

Ой! дорогой ты мой человек!!! чего ж я в субботу то это не увидел спасибо тебе, а я уже маляву накатал https://www.facebook.com/groups/postgresql/permalink/627585317438219/ сидел разбирался сегодня три часа с исходниками mamonsu...

надо сделать плагин, который будет таблицу периодически обновлять :) Григорий расказывал на PgConf как писать плагин :)

тут кто-то интересовался расценками на солидный постгрес для солидных господ. @vladimir_lyshenko ? так вот: http://www.1csoft.ru/publications/8143/23901658/?ELEMENT_ID=23901658

из той ссылки следует, что enterprise можно купить только пожизненно всего за 360 000 рублей за ядро. а версии 1С и standard можно купить с поддержкой на ограниченный срок

но судя по всему 1с гарантирует работу только с EE версией

а что будет, если купить на 1 ядро, а запустить на 100-ядерной машине?

как у оракла - все на честном слове

надо сделать плагин, который будет таблицу периодически обновлять :) Григорий расказывал на PgConf как писать плагин :)

Есть repl_mon. Сие поделие раз в интервал бгворкером пишет now, позицию и fqdn мастера в таблицу, на реплике можно с точностью до интервала измерять запросом лаг

Есть repl_mon. Сие поделие раз в интервал бгворкером пишет now, позицию и fqdn мастера в таблицу, на реплике можно с точностью до интервала измерять запросом лаг

ну это отдельный сервис, который надо права предоставлять и контролировать. проще в mamonsu сделать плагин который будет тоже самое писать

а это bgworker?

он в yum.postgresql.org есть?

ну это отдельный сервис, который надо права предоставлять и контролировать. проще в mamonsu сделать плагин который будет тоже самое писать

Это extension обычный, запускает bgworker

ERROR: S client not available

он в yum.postgresql.org есть?

в смысле его прийдется еще опакечивать и собирать, обновлять и менять конфиг :) а тут сторонний сервис который с работает с ванильным/любым pg как обычный клиент

в смысле его прийдется еще опакечивать и собирать, обновлять и менять конфиг :) а тут сторонний сервис который с работает с ванильным/любым pg как обычный клиент

https://github.com/dev1ant/repl_mon

если вы пг сами компилите, то можете прям в контриб чекаутить его и собирать с ним, можно через PGXS компилить

на проде где gcc не должно стоять? :)

ну а так, да, нужно в shared_preload_libraries его добавлять

ну пакеты же вы не на проде собираете

на проде где gcc не должно стоять? :)

хотя кого я обманываю, на проде с pg и gdb обязан стоять :)

хотя кого я обманываю, на проде с pg и gdb обязан стоять :)

ага, практика показывает, что да ?

ну пакеты же вы не на проде собираете

для этих пакетов еще и писать прийдется debian/control, spec и прочее :(

а потом еще и контролировать обновления :(

хотя я понял к чему вы клоните

что собираете свою версию

а что будет, если купить на 1 ядро, а запустить на 100-ядерной машине?

35640000 рублей недополученной прибыли

Ребята, здесь выше уже обсуждали партицирование, но хотелось бы задать еще пару вопросов. Допустим, есть большая таблица отношений UNIQUE(a,b). Записи в нее постоянно добавляются, их могут быть миллиарды. Очень часто нужно проверять, существует ли отношение (a, b) или находить всех b для указанного а. А теперь вопрос: есть ли смысл делать партицирование по а (например, по модулю N) для данных задач?

По сути, будет не одна огромная таблица, а N поменьше с теми же индексами. Насколько я понимаю, выиграш будет при чтении, потому что читать индекс конкретной таблицы быстрее, потому что он меньше (собственно, в N раз, если все распределено равномерно).

По сути, будет не одна огромная таблица, а N поменьше с теми же индексами. Насколько я понимаю, выиграш будет при чтении, потому что читать индекс конкретной таблицы быстрее, потому что он меньше (собственно, в N раз, если все распределено равномерно).

Проверка отношения это же запрос на чтение, если у тебя есть n таблиц поменьше. То в какой из таблиц проверять отношение ? Придётся во всех последовательно проверять. Это ничем не отличается от большого индекса, если не хуже. Т.к непонятно как твои таблицы упорядочены.

Проверка отношения это же запрос на чтение, если у тебя есть n таблиц поменьше. То в какой из таблиц проверять отношение ? Придётся во всех последовательно проверять. Это ничем не отличается от большого индекса, если не хуже. Т.к непонятно как твои таблицы упорядочены.

Нет, здесь понятно. Я планировал сделать партицирование по принципу a % n == номер_партиции, т.е. я точно буду знать, для какого a в какой партиции нужно искать данные.

Нет, здесь понятно. Я планировал сделать партицирование по принципу a % n == номер_партиции, т.е. я точно буду знать, для какого a в какой партиции нужно искать данные.

Мне кажется, что на чтение не будет особого прироста. Так как чтение из b дерева log по основанию кол-ва элементов на уровне дерева. У тебя будет по сути n деревьев меньшего размера. А вообще надо посчитать, насколько у деревьев будет меньше уровней, если ты их так разделишь. Точно не могу так сказать навскидку.

Надо подумать

навскидку 1000-2000 записей в одном узле (если int32). Допустим 1000. Тогда 2 уровня дерева это миллион записей, три уровня - миллиард

Нет, здесь понятно. Я планировал сделать партицирование по принципу a % n == номер_партиции, т.е. я точно буду знать, для какого a в какой партиции нужно искать данные.

Ну да, быстрее. У тебя по сути получается хеш таблица, а таблицы с индексами это бакеты в виде дерева

Ну да, быстрее. У тебя по сути получается хеш таблица, а таблицы с индексами это бакеты в виде дерева

Я просто хочу решить, стоит ли мучать такими задачами postgres или лучше сразу смотреть в сторону Cassandra, где все это можно будет легко распределить по узлам и все такое. :)

я вот прямо горел желанием порекомендовать взять хранилище, которое шардируется из коробки

но кассандра весьма ограничена по сравнению с классическим sql, какие-нибудь агрегации и джойны вы гонять не сможете

По сути, будет не одна огромная таблица, а N поменьше с теми же индексами. Насколько я понимаю, выиграш будет при чтении, потому что читать индекс конкретной таблицы быстрее, потому что он меньше (собственно, в N раз, если все распределено равномерно).

а сколько партиций планируете?

а сколько партиций планируете?

Хороший вопрос. Я думаю, можно сделать 100.

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

Хороший вопрос. Я думаю, можно сделать 100.

тогда рекомендую посмотреть на pg_pathman. Там и хеш-партиционирование без приседаний идет в комплекте