D
ахах
Size: a a a
2020 August 21
D
да, триггер самое оптимальное решение
D
тут уже просто интересно было, мол а вдруг есть что-то ещё проще
YS
почему хотел сделать одно значение на все записи - чтобы потом повесить на этот ряд UNIQUE и таким образом запретить создание новых записей
Так сколько у Вас записей-то? Если должно быть не более одной, можно сделать просто вот так:
CREATE TABLE x(
y text NOT NULL
);
CREATE UNIQUE INDEX ON x((1));
s
поговорил с аналитиками, им сейчас инетерсны данные за период 2008-2020, никаких четких планов по использованию других нет, так что я думаю под текущие задачи создать усеченную таблицу, потом ее прибить.
Если в запросах всегда будет указываться диапазон дат в условии (как в запросе выше было), то может тогда partial index просто создать для этого отрезка дат? По идее планировщик тогда будет смотреть строки по этому индексу и потом адресно забирать их из таблицы, не читая весь файл с ней с диска.
2020 August 22
L
влияет ли на производительность вставки
NOT NULL в столбцах?L
есть задача обновить таблицу на 150 млн строк новыми данными из свежей выгрузки, на хабре нашел статью с примерами как это делать силами pg, переделал под себя, теперь хочется понять какие лучше индексы сделать и в какой момент (особенно интересно нужны ли они в тот момент когда делается UPDATE/INSERT, потому что там сложные WHERE)?
Полный пример для воспроизведения выложил тут: https://pastebin.com/2bpcmqAT
Полный пример для воспроизведения выложил тут: https://pastebin.com/2bpcmqAT
L
да и вообще любые советы по оптимизации этого добра - приветствуются ))
🅵
да и вообще любые советы по оптимизации этого добра - приветствуются ))
ну по идее прост вставляешь пачками по 5000 записей и будет норм
🅵
150 миллионов не так уж и много
РЖ
В зависимости от таблицы и железа пачки от 1000 до 50000. В конце pg_repack натравить, т.к. вакуума можно будет ждать до морковкиного заговения.
Лично я на каждой итерации делал темповую таблицу со списком записей для изменения и потом по этому списку обновлял. Заодно можно в этой же транзакции блокировки на эти записи повесить.
Лично я на каждой итерации делал темповую таблицу со списком записей для изменения и потом по этому списку обновлял. Заодно можно в этой же транзакции блокировки на эти записи повесить.
s
есть задача обновить таблицу на 150 млн строк новыми данными из свежей выгрузки, на хабре нашел статью с примерами как это делать силами pg, переделал под себя, теперь хочется понять какие лучше индексы сделать и в какой момент (особенно интересно нужны ли они в тот момент когда делается UPDATE/INSERT, потому что там сложные WHERE)?
Полный пример для воспроизведения выложил тут: https://pastebin.com/2bpcmqAT
Полный пример для воспроизведения выложил тут: https://pastebin.com/2bpcmqAT
Varchar(70) - мой любимый антипаттерн. Зачем ограничивать какую-то строку, даже если это чисто пример? Просто varchar()
AN
А если туда согласно бизнес-правилам запихивать больше нельзя?
A
Alexander Nikitin
А если туда согласно бизнес-правилам запихивать больше нельзя?
Ну так пусть бизнес-правила применяются в бизнес-логике.
AN
Да понятно
AI
Varchar(70) - мой любимый антипаттерн. Зачем ограничивать какую-то строку, даже если это чисто пример? Просто varchar()
Чтобы там не появилось гигабайта на поле имя?
P
Тогда в чем разница varchar() и text
A
Petr
Тогда в чем разница varchar() и text
Ни в чем
A
Более того, вместо varchar(n) некоторые рекомендуют юзать text с check constraint-ом.
M
Alexander
Более того, вместо varchar(n) некоторые рекомендуют юзать text с check constraint-ом.
А это разве не дороже по времени вставки будет в это поле?