Ну чисто теоритически, так как времени на эсперементы нет

Есть объекты квартиры которые деляться на аренду и продажу. Все поля одинаковые, кроме аренды и продажи. Можно две таблицы сделать, а можно и одну, но что быстрее будет?

А какая разница, что будет быстрее? У Вас "сервер" на Raspberry Pi, что ли? ;) (Нет бы правильную модель сделать...)

А какая разница, что будет быстрее? У Вас "сервер" на Raspberry Pi, что ли? ;) (Нет бы правильную модель сделать...)

А в чем модель неправильная то?

А какая разница, что будет быстрее? У Вас "сервер" на Raspberry Pi, что ли? ;) (Нет бы правильную модель сделать...)

Postgresql из-за скорости еще выбрал

А в чем модель неправильная то?

Вы предложили две, как я понял? Почему бы просто не использовать ту, которая правильнее в Вашем случае?

Вы предложили две, как я понял? Почему бы просто не использовать ту, которая правильнее в Вашем случае?

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

Pg_roles показывает пароли, но информацию о том где что хоанит тут не нашёл

1. вы невнимательно смотрите документацию: pg_roles - это вьюха, и в самом начале доки по ней есть ссылка на табличку, откуда берутся данные; 2. вы невнятно формулируете вопрос, из которого совсем непонятно, чего вы добиваетесь;

1. вы невнимательно смотрите документацию: pg_roles - это вьюха, и в самом начале доки по ней есть ссылка на табличку, откуда берутся данные; 2. вы невнятно формулируете вопрос, из которого совсем непонятно, чего вы добиваетесь;

Хочу понять как и где хранятся создаваемые роли

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

Т.е. у Вас ссылок на эти квартиры нигде не будет? И набор свойств у этих сущностей одинаковый?

Т.е. у Вас ссылок на эти квартиры нигде не будет? И набор свойств у этих сущностей одинаковый?

Ссылок в другие таблицы нет. Да все поля все одинаковые, кроме аренды и продажи

Ссылок в другие таблицы нет. Да все поля все одинаковые, кроме аренды и продажи

У вас два столбца: аренда и продажа что ли? И что там?

У вас два столбца: аренда и продажа что ли? И что там?

Почему, столбцов много. Но они все одинаковые у этих объектов (площадь, количество комнат, тип квартиры и т.д.). Но если хранить объекты в одной таблицы (те которые на продажу и те кторые на аренду), то надо будет добавить столбец (продажа/аренда). Либо сделать две таблицы. В одноцй будут хранится объекты на продажу, в другой на аренду. Но эти таблицы будут абсолютно одинаковые по столбцам. В выборке в первом случае надо будет указать аренда или продажа и делать выборку из одной таблицы, во втором просто выбрать таблицу и туда делать запросы на нужные параметры

И соотвественно в первом случае в таблицы будут 200 000 объектов и одна таблица, а во втором 100 000 объектов и 2 таблицы

сотни тысяч записей в таблицах - это не вот уж объём. Если вы в каждой записи не собираетесь ПСС В.И. Ленина хранить.

Или Л.Н. Толстого.

нет)

Хотя... Война и мир, например, всего-то 3Мб весит в KOI-8.

@winnie_ua будет жить. Поприветствуем!

И соотвественно в первом случае в таблицы будут 200 000 объектов и одна таблица, а во втором 100 000 объектов и 2 таблицы

В таком случае, всё равно правильный способ хранения зависит от того, что в модели "вокруг" этой/этих таблиц. А если ничего нет... то это несколько странная модель, мне кажется.

В таком случае, всё равно правильный способ хранения зависит от того, что в модели "вокруг" этой/этих таблиц. А если ничего нет... то это несколько странная модель, мне кажется.

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

что бы сократить количество объектов в одной таблице

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

Да это ясно, что оно одинаковое. Вопрос в том, какое оно. > Имеет ли смысл одну таблицу с сотней тысяч объектов разделить на две? Просто так, без причин? Нет, не имеет, IMHO.

Да это ясно, что оно одинаковое. Вопрос в том, какое оно. > Имеет ли смысл одну таблицу с сотней тысяч объектов разделить на две? Просто так, без причин? Нет, не имеет, IMHO.

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

и так все остальные столбцы

вот так https://postgrespro.ru/docs/postgresql/10/tutorial-fk

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

Вы бы лучше схему показали, чем её пересказывать. Может, Вам по ней дали бы и других полезных советов...

Схема не совсем еще готова, например стоят varchar вместо int так как удобно было так отлаживать

Схема не совсем еще готова, например стоят varchar вместо int так как удобно было так отлаживать

А это "учебная" схема, или Вы ей на самом деле собираетесь пользоваться? А по самой схеме: получается, что на apartments_sale всё "кончается", т.е. на неё уже никаких сслылок не будет и т.п.?

varchar вместо int так как удобно было так отлаживать У вас связей нету между табилцами, город /область/раен ни как не ссылаются друг на друга и на страну

И соотвественно в первом случае в таблицы будут 200 000 объектов и одна таблица, а во втором 100 000 объектов и 2 таблицы

200_000 это не то к-во строк, где надо задумываться про шардинг но овбще разбить можно на две таблицы, но как я понимаю логикаповедения во многом общая у вас, смысла большого нет

А это "учебная" схема, или Вы ей на самом деле собираетесь пользоваться? А по самой схеме: получается, что на apartments_sale всё "кончается", т.е. на неё уже никаких сслылок не будет и т.п.?

Да не будет, а зачем?

varchar вместо int так как удобно было так отлаживать У вас связей нету между табилцами, город /область/раен ни как не ссылаются друг на друга и на страну

Да, убрал временно для отладки

Да не будет, а зачем?

Да откуда мне-то знать? ;) Это же Ваша модель. Если бы были, был бы другой разговор... а так, по большому счёту, неважно, сколько тут таблиц; но, с другой стороны, непонятно, почему Вам хочется "разбить" именно по этому признаку, а не по любому (или даже нескольким, а то и по всем ;) ) другому boolean (например, mortgage)? ;) В самом деле, Вы можете себе ответить на вопрос "почему нет?" или "чем именно признак продажа/аренда такой особенный?"?

Да откуда мне-то знать? ;) Это же Ваша модель. Если бы были, был бы другой разговор... а так, по большому счёту, неважно, сколько тут таблиц; но, с другой стороны, непонятно, почему Вам хочется "разбить" именно по этому признаку, а не по любому (или даже нескольким, а то и по всем ;) ) другому boolean (например, mortgage)? ;) В самом деле, Вы можете себе ответить на вопрос "почему нет?" или "чем именно признак продажа/аренда такой особенный?"?

Запросы будут идти на квартры либо аренда либо продажа плюс фильтры. select * from apartments_sale where .... Тоесть искать будут либо продажу плюс фильтры, либо аренду плюс фильтры. В выдаче не будет и аренды и продажи вместе, поэтому удобно так разбить

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

но как я понял это на таких количествах объектов не так важно

спасибо

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

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

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

стоит? не стоит?

ну и применение в рамках озвученной выше задачи про квартиры?

стоит? не стоит?

Почти наверняка не стоит (только для партиционирования и каких-нибудь "трюков", но не для моделирования).

стоит? не стоит?

не стоит, есть ограничения… Для партицирования лучше сразу pg_pathman использовать.

добрый день. в pg11 завезли проверку чексумм для бэкапов и pg_basebackup совместим со старыми версиями. но будет ли он для старых версий делать проверку?

@diogenes228 будет жить. Поприветствуем!

У меня вопросы сразу. Мне чтобы distinct on использовать, надо в ордер бай указать все перечисленные колонки, правильно?

И могу ли я как-то постусловия фильтрации добавить

или же мне придется делать select * from ( select distinct on... ) where column = ...?

добрый день. в pg11 завезли проверку чексумм для бэкапов и pg_basebackup совместим со старыми версиями. но будет ли он для старых версий делать проверку?

Так они же на источнике проверяются. Так что, нет.

У меня вопросы сразу. Мне чтобы distinct on использовать, надо в ордер бай указать все перечисленные колонки, правильно?

Да, по крайней мере их (SELECT DISTINCT ON expressions must match initial ORDER BY expressions). И да, чтобы фильтровать после DISTINCT ON, Вам понадобится вложенный запрос.

Так они же на источнике проверяются. Так что, нет.

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

погрустнел

Да, по крайней мере их (SELECT DISTINCT ON expressions must match initial ORDER BY expressions). И да, чтобы фильтровать после DISTINCT ON, Вам понадобится вложенный запрос.

мда, спс. Не подходит чет мне ниче.

блин. значит, что валидация чексумм при бэкапах дороже, чем я думал, для кластера..

блин. значит, что валидация чексумм при бэкапах дороже, чем я думал, для кластера..

Вряд ли существенно (не зря она включена по умолчанию, мне кажется).

тут вроде есть некоторое противоречие, так как ее включили в бэкапах, но не включают в initdb

тут вроде есть некоторое противоречие, так как ее включили в бэкапах, но не включают в initdb

Да вроде нет. ;) Тем, какую нагрузку на сервер создаёт pg_basebackup, можно управлять, в отличие от влюченных checksums в initdb. Другой вопрос, почему бы их не сделать включенными по умолчанию в initdb...

пацаны, тут как-то советовали pghero

под freebsd его никто не ставил?

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

используя alias, например: SELECT a.code AS a_code, b.code AS b_code FROM a, b

используя alias, например: SELECT a.code AS a_code, b.code AS b_code FROM a, b

спасибо)

Доброго времени суток всем! Кто подскажет Postgres-BDR на данный момент полностью совместим с 9.6? Или вообще нет?

Так как раньше он под 9.4 только был в качестве расширений и патчей, потом вроде как некоторые из них в ядро 9.6 попали, но без sequence access method patchа, как сейчас?

в открытом доступе только 1 версия для 9.4. 2 и 3 релиз небесплатен. Если ничего не поменялось

в открытом доступе только 1 версия для 9.4. 2 и 3 релиз небесплатен. Если ничего не поменялось

Спасибо.

Подскажите плз, как написать запрос, который будет искать все идентичные rows(отличаются только id)

Подскажите плз, как написать запрос, который будет искать все идентичные rows(отличаются только id)

count + group by

Подскажите плз, как написать запрос, который будет искать все идентичные rows(отличаются только id)

Или PARTITION BY + COUNT с вложенным запросом (если сразу нужны сами rows).

возможно ли скопировать базу с дев окружения на локальное, при этом сохранив все ключи(pk/fk/etc) ?

обычный pg_dump/pg_restore позволяет развернуть базу, но при этом генерируются другие айдишники для записей

обычный pg_dump/pg_restore позволяет развернуть базу, но при этом генерируются другие айдишники для записей

очень странно, pg_restore восстаналнивает как айдишники так и sequence'ы что то вы делали не так

Что-то не верится

правда там, с AWS / Google Cloud могут быть нюансы с правми доступа

полагаю необходимые параметры не указал

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

ok.

ага, получилось, спасибо)

@tookan будет жить. Поприветствуем!

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