postico ftw

это что?

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

maintaince_work_mem увеличить.

сильно?

никто не знает или я спросил слишком глупый вопрос? ?

Параметр очень влияет на скорость построения больших индексов. У меня на 24 гигах ram при обслуживании сервера - 8гб выставлено. Зависит от размера индекса

Можно выставить много, развернуть, а потом снизить?

Можно выставить много, развернуть, а потом снизить?

Да

Я так и делаю

спасибо

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

всмысле таблица C наследуется от B, которая наследуется от A? Может

всмысле таблица C наследуется от B, которая наследуется от A? Может

а это считается нормальным решением или не очень?

с такими проблемами больше проблем не будет (чем с остальными таблицами, которые наследуются только от одной таблицы)?

Я не очень понял зачем тебе вообще наследование. 99.99% случаев оно тебе не нужно

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

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

ну вот в примере выше - таблица sftp_connections наследуется от ssh_based_connections, которая наследуется от connections

b.parent_id, c.parent_id, a.id — вот тебе без наследования.

+ я не совсем уверен, что ты понимаешь, что id во всех3 таблицах будет сквозной.

Это реально не всегда подходит, даже когда тебе "типа"надо наследование

так это и хорошо, это позволяет связать с подключением что угодно как если бы это была 1 таблица

с такими проблемами больше проблем не будет (чем с остальными таблицами, которые наследуются только от одной таблицы)?

проблема может быть, если ссылаешься на родительскую таблицу из других релейшенов (foreign key)

т.к. в постгресе нет глобального индекса для иерархии таблиц

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

Сделали через обычные ключи

проблема может быть, если ссылаешься на родительскую таблицу из других релейшенов (foreign key)

то есть если у меня есть А, наследующаяся от Б, наследующаяся от В, то я не должен хотеть связывать А с другой Б?

Привет. Есть небольшая постгрес база. Периодически на ней одним хорошим человеком выполняются различные скрипты, которые прилетают от веб-разработчиков. Скрипты могут как править определение данных так и сами данные. Хочется все это положить в гит, но при этом чтобы было легко отслеживать все изменения в схеме, то есть просто засовывать всё входящее - не подходит. Мне приходит на ум два варианта: 1) к каждому скрипту прилагать файл или несколько с изменениями схемы, которые вносит исполняемый скрипт. Но это мягко выражаясь не удобно 2) Замутить какой нибудь хук, который после коммита выполнит скрипт, найдет изменения в структуре базы и сделает из этого дополнение к коммиту. Это удобно, но как-то стремновато совсем, скрипты автоматически выполнять :) Вот такая проблема. Подскажите, пожалуйста, может это и не проблема и я все надумал? Или все же проблема и для нее есть нормальное решение :) Фух, аж устал с телефона писать :)

Да. Они уже связаны

а вариант с отдельными таблицами вообще чем-то лучше, чем 1 большая таблица с неиспользуемыми полями? (просто было бы удобно иметь общий ID на все типы подключений)

Привет. Есть небольшая постгрес база. Периодически на ней одним хорошим человеком выполняются различные скрипты, которые прилетают от веб-разработчиков. Скрипты могут как править определение данных так и сами данные. Хочется все это положить в гит, но при этом чтобы было легко отслеживать все изменения в схеме, то есть просто засовывать всё входящее - не подходит. Мне приходит на ум два варианта: 1) к каждому скрипту прилагать файл или несколько с изменениями схемы, которые вносит исполняемый скрипт. Но это мягко выражаясь не удобно 2) Замутить какой нибудь хук, который после коммита выполнит скрипт, найдет изменения в структуре базы и сделает из этого дополнение к коммиту. Это удобно, но как-то стремновато совсем, скрипты автоматически выполнять :) Вот такая проблема. Подскажите, пожалуйста, может это и не проблема и я все надумал? Или все же проблема и для нее есть нормальное решение :) Фух, аж устал с телефона писать :)

мож ваще не в кассу, но глянь на http://www.liquibase.org/ может ваш кейс

то есть если вместо наследования таблиц просто сделать 1 большую таблицу

мож ваще не в кассу, но глянь на http://www.liquibase.org/ может ваш кейс

+ phinx, если у вас PHP основной ЯП

+ phinx, если у вас PHP основной ЯП

это не тот что баду юзает, не?

не знаю, если честно

то есть если у меня есть А, наследующаяся от Б, наследующаяся от В, то я не должен хотеть связывать А с другой Б?

нет, я имел в виду, что если есть некая отдельная Г, которая ссылается на некий ключ из A, то с этим могут быть проблемы. Например, в А, Б и В есть ключ id (наследуется из А). Г ссылается на ключ A.id (пусть будет Г.a_id). Вставляем в Б запись с id = 1. Теперь хотим вставить в Г запись a_id = 1 и получаем облом - нарушение целостности, т.к. в A этого ключа нет

хотя, например, 'select id from A' вернет запись с id=1

мож ваще не в кассу, но глянь на http://www.liquibase.org/ может ваш кейс

Спасибо, погляжу

а, понял.. но это вручную контроллируется и мы точно уверены, что такое не случится, то каких-либо других проблем нет?.. на производительность такое множественное наследование сильно влияет?

а, понял.. но это вручную контроллируется и мы точно уверены, что такое не случится, то каких-либо других проблем нет?.. на производительность такое множественное наследование сильно влияет?

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

понял, а вот все эти вещи типа партиционирование / репликация / шардинг - это всё с такими таблицами ок работает?

репликация работает. Партиционирование - смотря как сделаете, оно ведь тоже на наследовании : )

по идее будет работать. Нужно только проверить, как работают экстеншены для партиционирования, если вы их планируете использовать

могу завтра на pg_pathman попробовать

спасибо) конкретно сейчас мне достаточно просто 1 базы данных на 1 сервере, это, скорее, на всякий случай спросил, чтобы оценить, какие проблемы могут возникнуть, если вдруг такое понадобится (а такое может понадобиться в будущем)

а вариант с отдельными таблицами вообще чем-то лучше, чем 1 большая таблица с неиспользуемыми полями? (просто было бы удобно иметь общий ID на все типы подключений)

иногда лучше, особенно если в одной большой таблице много колонок – не нужно читать с диска лишние данные. Следовательно ускоряется чтение, буффер кеш не забивается

а вот это решение с наследованием - его стоит принять в начале пути при проектировании или же в будущем, если ошибся и уже много данных в таблице, всё же получится исправить ошибку?

насколько велика цена ошибки в данном случае?

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

а какого порядка куча?

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

ну, не такая уж большая, если честно) в пределах 100 тысяч кортежей

я ступил тут... да, всё можно переделать, просто не менять, а делать новые таблицы, переносить туда и удалять старые

с наследованием еще такая проблема, что если вдруг придется переносить (как бы антипатриотично это ни звучало) на другую субд, то вряд ли там будет аналог : )

речь ведь про NoSQL?

или есть поводы переносить на другие SQL?

статьяуберапромускул.хтмл

эх, я думал, Postgres тут лучшая и всех рвёт ?

а вариант с отдельными таблицами вообще чем-то лучше, чем 1 большая таблица с неиспользуемыми полями? (просто было бы удобно иметь общий ID на все типы подключений)

сквозные id-ы можно настроить и для отдельных несвязанных таблиц используя sequence. Но опять же foreign key с такой конфигурацией работать не будут

Если серьезно, то разные штуки бывают. Однажды пришлось переезжать с постгре на мускул, потому что нужно было перетащить микросервис в другой проект, и там особо средств не было, чтобы иначе это организовать.

Вот защищал я DataGrip и чот сейчас бомбануло. Не могу через их редактор вставить строку, где одно из полей имеет тип POINT

багу заведи, они часто сегодня-на-завтра чинят

багу заведи, они часто сегодня-на-завтра чинят

Баги по PHPStorm у меня висят годами

Уверен?

ну, мои - чинят

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

хотя, посмотрел, из моих 26 репортов починили 12

основная часть непочиненных "вот тут форматтер ведёт себя не очень"

Запилил репорт им

полайкал

ещё вместо наследования, наверное, можно сделать 1 таблицу и туда вставить поле с типом hstore

эмм, 2016, скоро 2017, hstore?

Да, 1 таблицу с 1 полем jsonb и все там хранить.

выбор хранилища зависит от производительности. так что пусть хоть ',' +join(',', @ids) + ','

Хм? Это какое-то очень троллинговое утверждение

это типичный вариант хранения массива ids с поиском по оным. к postgres слабо относится.

> выбор хранилища зависит от производительности. я имею в виду вот это утверждение и его общность

флаг в руки и барабан на шею, хотя, вероятно, я могу быть неправ. но история говорит, что производительность СУБД - ключевой фактор.

Просто сейчас почти у всех популярных "хранилищ" интервал производительности охватывает типичный проект. И нету между ними особой разницы.

это помимо остальных свойств СУБД. речь о выборе техник внутри технологии

тут я промолчу.

Самое быстрое хранилище - это memcache )

"внутри технологии" - подразумевало ACID etc.

Самое быстрое хранилище - это memcache )

это пока у него на паттерн вытеснения не попадёшь

Самое быстрое хранилище - это memcache )

Древность.

Оно от этого факта медленнее не стало

ок, в чем мы измеряем скорость? во времени, потраченном на единственную запись?

пипл, не та группа. но если оффтопить, - memcached хорош. просто он мало что умеет.

P.S.: для всех memstore обычно вся задержка чтения/записи = сетевая )

я люблю redis, хотя он типа тоже устарел )

"устарел" - вообще какой-то сферический термин

Как и "производительность"

как и "самое быстрое хранилище"

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

я знаю правильный термин - немодный )

Или оценивать нужно по другому критерию?

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

а чем продиктовано само желание перейти?

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

нет

Желанием разработчика

если он никак это не аргументирует, то вряд ли