К тому же, если все миллион пользователей будут онлайн. Тогда в каждой таблице буду создаваться подзапросы с numrow. В тоже время в случае с materialized view будет один сброс таблицы, зато миллион запросов пойдут через индексы

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

я запутался, кто из них 8, кто 1))

1-ый - это первый день. 8-ой - 8 день, который уходит в мусор.

К тому же, если все миллион пользователей будут онлайн. Тогда в каждой таблице буду создаваться подзапросы с numrow. В тоже время в случае с materialized view будет один сброс таблицы, зато миллион запросов пойдут через индексы

да, чистая правда. но остается момент перестроения таблицы.

Ну его можно сделать конкурентным в начале минуты. Даже если не успеет за минуту, то просто возьмутся старые данные

Потому на уровне приложения уже находим строку с заданным userId и относительно неё отсчитываем 10 сверху и 10 снизу

Мы в PG Pro Enterprise сделали функцию поиска n ближайших соседей по индексу (KNN), но вот не могу сходу доку на неё найти. Завтра спрошу коллег

Мы в PG Pro Enterprise сделали функцию поиска n ближайших соседей по индексу (KNN), но вот не могу сходу доку на неё найти. Завтра спрошу коллег

Да, спасибо, но эту проблему уже решили с помощью btree_gist индекса и union запросов :)

Вот и замечательно

тогда лучше это)

Мы в PG Pro Enterprise сделали функцию поиска n ближайших соседей по индексу (KNN), но вот не могу сходу доку на неё найти. Завтра спрошу коллег

о так это ж круто и как работает?

подскажите такой вопрос создаю первую таблицу CREATE TABLE "settings" ( "id" SERIAL NOT NULL, "module" CHARACTER VARYING(30), "value" TEXT, CONSTRAINT "PRIMARY" PRIMARY KEY ("id") ); пытаюсь создать вторую CREATE TABLE "districts" ( "id" SERIAL NOT NULL, "title" CHARACTER VARYING(100), "visible" INT DEFAULT 1, CONSTRAINT "PRIMARY" PRIMARY KEY ("id") ); выдаёт вот такое ERROR: SQLSTATE[42P07]: Duplicate table: 7 ERROR: relation "PRIMARY" already exists

ну дык констрейнты назовите по разному

Вы создали в первом выражении таблицу settings и индекс primary. Вторым выражением создаёте таблицу districts и опять индекс с названием primary. Вот на это и ругается постгрес, имена индексов должны быть уникальны

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

о так это ж круто и как работает?

В моем понимании- это поход по индексу "в бок", а не вверх и низ по дереву. Соответственно берем 10 соседей и результат готов.

спасибо за ответ

Всем привет! Прошу поделиться опытом как в бою добавляют поля в PK, на который другие FK ссылаются. Может статьи есть по теме хорошие?

Не улавливаю связи с FK, но вообще pkey пересоздается: ALTER TABLE table DROP CONSTRAINT table_pkey, ALTER TABLE table ADD PRIMARY KEY (new fields);

Но я бы выслушал кого-нибудь ещё, вдруг я ошибаюсь.

Связь уловил. Ну да, в случае если прошлое поле станет неуникальным

Если оно остается уникальным – можно добавить же unique индекс

Если поле станет неуникальным – вам придется создать "словарик" отдельно и вешать зависимости уже на него. Если останется – добавить unique на поле. Способов проще по-моему нету.

Ситуация думаю что типовая, но я сейчас туплю. Попробовал в лоб дропнуть и создать PK, он мне вывалил 2BP01 dependent_objects_still_exist. На таблицу, в которой я пытаюсь поменять ключ ссылается другая. drop cascade и пересоздание индексов по всем ссылающимся делать не хочется. Быстрое гугление выдало грязный хак в виде отключения проверки целостности, что тоже в бой нельзя вываливать.

То есть задача добавить новое поле в таблицу, и добавить его в ключ, но связи мешают.

А вам точно надо пересоздавать ПК? А уникальным ключом обойтись, если надо для ссылочной целостности, не хватит?

FOREIGN KEY - оно же совсем необязательно на ПК ссылаться должОн. Ему вполне себе уникальности достаточно.

А зачем вам нужно добавлять в первичный ключ дополнительные поля? Нельзя ли просто добавить дополнительный индекс?

по сути, мне надо делать новую таблицу-справочник, и загонять в неё новое поле, и связывать с родительской, чтобы оно было уникальным. Но в процессе возник интерес, а как это в продуктиве можно провернуть с ключами. Забыли, например ещё одно поле в составной PK добавить. И вот тут надо всё нафиг разбирать до крайнего потомка, ломать проверку целостности или как-то можно полегче вывернуться.

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

понятно, спс

Полегче - это не плевать на этап проектирования БД при написании приложения, как это бывает в подавляющем большинстве случаев наличия подобных проблем. По-другому - никак. А проверять целостность на уровне приложения - а для зачем тогда СУБД?

по сути, мне надо делать новую таблицу-справочник, и загонять в неё новое поле, и связывать с родительской, чтобы оно было уникальным. Но в процессе возник интерес, а как это в продуктиве можно провернуть с ключами. Забыли, например ещё одно поле в составной PK добавить. И вот тут надо всё нафиг разбирать до крайнего потомка, ломать проверку целостности или как-то можно полегче вывернуться.

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

спасибо!

И разбирать в описанной вами ситуации ничего не надо. Как и новую таблицу создавать. Вообще, я рекомендую книжку Рефакторинг баз данных, эволюционное проектирование. В ней все уже украдено до нас и подробно разбираются паттерны как что добавлять и менять на продакшене

Полегче - это не плевать на этап проектирования БД при написании приложения, как это бывает в подавляющем большинстве случаев наличия подобных проблем. По-другому - никак. А проверять целостность на уровне приложения - а для зачем тогда СУБД?

чтобы хранить данные? ?

по сути, мне надо делать новую таблицу-справочник, и загонять в неё новое поле, и связывать с родительской, чтобы оно было уникальным. Но в процессе возник интерес, а как это в продуктиве можно провернуть с ключами. Забыли, например ещё одно поле в составной PK добавить. И вот тут надо всё нафиг разбирать до крайнего потомка, ломать проверку целостности или как-то можно полегче вывернуться.

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

Для просто хранить данные вон файловой системы достаточно.

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

А я про что?

Сейчас начнётся (взял попкорн)

А я про что?

так я не тебе же этим комментарием отвечал

Ну, звиняй, боярин, бес попутал. Однако.

Разочаровано убрал попкорн, ложная тревога

вбросить про акапитализм и waterfall vs agile?

вбросить про акапитализм и waterfall vs agile?

А что значат эти страшные наглосакские термины?

(методологии разработки ПО https://ru.wikipedia.org/wiki/Гибкая_методология_разработки/). ну то есть в современных условиях никто денег не даст нормально проектировать. Те, у кого деньги есть - уже всё напроектировали, и давят конкурентов ценами. Молодые да резвые не могут тратить нормально времени на проект, надо деплоить в продакшен. Вот такая грусть-печаль.

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

капитализм+дрожащиепальцы=акапитализм

вот вам по теме : https://www.youtube.com/watch?v=QJ58nCY6sPM&list=PLQCYG6lKBuTaJkaxbrdoZdGjFpTFwI-o0

Всем привет. Подскажите почему в запрос не подставляется имя передаваемое через параметр

create or REPLACE function temp.update_intid(count integer, count2 integer, nameTable CHARACTER VARYING(50)) returns void AS $$ DECLARE i integer; j INTEGER; begin i:=1; j:=count2; WHILE i<count loop update nameTable set intid=j where intid2=i; i:=i+1; j:=j+1; END loop; end; $$ LANGUAGE plpgsql VOLATILE COST 100; ALTER FUNCTION temp.update_intid(integer,integer,character varying(50)) OWNER TO postgres;

Во-первых, count рарезервированное слово.

Значения переменным можно присваивать прямо в declare - меньше кода будет.

А почему вы решили, что не передаётся?

Ааа.

Надо execute использовать.

ERROR: S client not available

execute format('update %s set ...', nameTable);

А сами значения i и j биндить с помощью $

Как-то так

create or REPLACE function temp.update_intid(count1 integer, count2 integer, nameTable CHARACTER VARYING(50)) returns void AS $$ DECLARE i INTEGER := 1; j INTEGER := count2; BEGIN WHILE i < count1 loop EXECUTE format('update %s set intid=$1 where intid2=$2', nameTable) USING j, i; i:=i+1; j:=j+1; END LOOP; END; $$ LANGUAGE plpgsql VOLATILE COST 100; ALTER FUNCTION temp.update_intid(integer,integer,character varying(50)) OWNER TO postgres;

все отлично работает. спасибо огромное. теперь буду знать

create or REPLACE function temp.update_intid(count integer, count2 integer, nameTable CHARACTER VARYING(50)) returns void AS $$ DECLARE i integer; j INTEGER; begin i:=1; j:=count2; WHILE i<count loop update nameTable set intid=j where intid2=i; i:=i+1; j:=j+1; END loop; end; $$ LANGUAGE plpgsql VOLATILE COST 100; ALTER FUNCTION temp.update_intid(integer,integer,character varying(50)) OWNER TO postgres;

У меня только один вопрос - почему цикл и курсоры для обновления?!

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

Возможно это имитация задержки

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

почему не что-то вроде update %s set intid=intid-count2 where intid between count2 and count2+count1; ?

а почему не проставить их при переносе через row_number() order by id?

а почему не проставить их при переносе через row_number() order by id?

+++

row_number() вернет номер строки?

row_number() вернет номер строки?

Да, посмотрите оконные функции

я не могу понять пока как мне это поможет

это убьёт функцию целиком и заменит её на один вызов row_number() в копировании

так row_number() нельзя же задать с какого числа начинать

так row_number() нельзя же задать с какого числа начинать

К нему можно это число прибавить))

точно))

спс.

Вообще loop - это императивный подход, а sql все же подразумевает декларативность. Я могу высказаться слишком резко, но мое мнение - циклам не место в хранимых процедурах, их всегда можно заменить на средства sql (тот же lateral join). До 9.5 цикл использовался в одном широко известном паттерне-костыле вместо upsert, но с появлением on conflict - циклы должны умереть)

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

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

Тут нужно смотреть конкретные примеры. Я просто не уверен, что такие вещи должны решаться на уровне функций базы, а не на сервере приложения

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

как это посчитать в приложении? :)

Думаю, никак)) Я скажу больше, я даже не знаю оптимального алгоритма, как решать. Но я обдумаю на досуге

народ, надо ли в постгресе роли, созданной для обращений к БД приложением из локалки, давать пермишен login?

Думаю, никак)) Я скажу больше, я даже не знаю оптимального алгоритма, как решать. Но я обдумаю на досуге

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