Size: a a a

pgsql – PostgreSQL

2021 July 01

С

Сергей in pgsql – PostgreSQL
Как вариант, но производительность падает с увеличением количества записей
источник

I

Id in pgsql – PostgreSQL
а через подзапрос с Limit?
источник

AK

Anton Kazachkov in pgsql – PostgreSQL
Он не запустится, конечно. Тут, скорее вопрос логики-нужна ли целевая вставка данных с неподтвержденным/непонятным translationId.
источник

T

Talgatio in pgsql – PostgreSQL
Да нужна. Новая запись или создаётся и берётся айдишник и если запись уже существует то берётся айдишник существующей
источник

С

Сергей in pgsql – PostgreSQL
Нужно по одной записи для каждой группы. LIMIT с GROUP BY не сочетается, насколько мне известно
источник

I

Id in pgsql – PostgreSQL
сорян, проглядел
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
коллеги, привет, подскажите, плз, советом

столкнулся с тем, что есть таблица текущего состояния сущностей, в ней есть поле targetdate - timestamptz, в таблице ~100М строк
пользователи делают много и очень часто запросов, где им нужно вернуть только строки, у которых targetdate отстоит от "сегодня" на какое-то количество дней в плюс и в минус, все происходит внутри проприетарного клиента, который предоставляет юзеру возможность оперировать заранее определенными функциями, то есть для юзера условие "targetdate = сегодня + 15 дней" выражается в таком виде:
DateOnly(L1.targetdate, 'Europe/Moscow') = AddDays(DateOnly(GetDate(), 'Europe/Moscow'), 15)

но работает это все из рук вон медленно, ради интереса распотрошил все определенные клиентом функции и получилось страшное месиво, вот такое:
(timestamp '1970-01-01 00:00:00' + trunc(cast(Extract(epoch from L1.targetdate at time zone 'Europe/Moscow' - timestamp '1970-01-01 00:00:00') / 86400 as numeric)) * 86400 * interval '1 second') at time zone 'Europe/Moscow' = (timestamp '1970-01-01 00:00:00' + Trunc(Extract(epoch from clock_timestamp() at time zone 'Europe/Moscow' - timestamp '1970-01-01 00:00:00') / 86400) * 86400 * interval '1 second') at time zone 'Europe/Moscow' + cast(text(15 * 86400) as interval) + (extract(timezone from (timestamp '1970-01-01 00:00:00' + Trunc(Extract(epoch from clock_timestamp() at time zone 'Europe/Moscow' - timestamp '1970-01-01 00:00:00') / 86400) * 86400 * interval '1 second') at time zone 'Europe/Moscow') - extract(timezone from (timestamp '1970-01-01 00:00:00' + Trunc(Extract(epoch from clock_timestamp() at time zone 'Europe/Moscow' - timestamp '1970-01-01 00:00:00') / 86400) * 86400 * interval '1 second') at time zone 'Europe/Moscow' + cast(text(15 * 86400) as interval)) ) * '1 second'::interval

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

I

Id in pgsql – PostgreSQL
а партиции попробуйте сделать, посуточно
источник

R

Radist in pgsql – PostgreSQL
> / 86400
Честно говоря, мы так в оракле писали, в postgresql есть нормальный interval.

> targetdate отстоит от "сегодня" на какое-то количество дней
чтобы такое быстро работало, стройте два условия (вариант если нужно с точностью до дня считать, если с большей точностью, то date_trunc убирается и вообще можно обычный between наверное):
targetdate >= date_trunc('day', текущая дата) - interval 'P15D' and
targetdate < date_trunc('day', текущая дата) + interval 'P16D'

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

AT

Andrey Tatarnikov in pgsql – PostgreSQL
сами по себе юзкейсы простые, сравнивать в WHERE две даты на больше/меньше/равно
при этом к датам надо уметь прибавлять/отнимать дни, точность - день, но с соблюдением таймзоны
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
и я пытаюсь понять вот такая простыня, которую по сути выполняет клиент, если ее заменить на что-то более простое - есть ли шанс, что простыня приносит какой-то ощутимый оверхед , или это все ерунда и надо передумывать то как данные хранятся и используются в целом
источник

V

Valery in pgsql – PostgreSQL
Дичь какая-то... Двойной пересчет времени из timestamptz в numeric и обратно да ещё и интервалы пересчитываются также.... А на клиенте границы интервала нельзя было вычислить?
источник

AT

Andrey Tatarnikov in pgsql – PostgreSQL
В смысле конкретную дату задать на клиенте? Нет.
источник

С

Сергей in pgsql – PostgreSQL
Я так понимаю, способов без снижения производительности нет?
источник

ГР

Геннадий Романов... in pgsql – PostgreSQL
Table A (id, date1)    Table B (id, date2)
Если для пересчета date1
нужно A LEFT JOIN B
date1 = max(date1, date2)

для всех id A это можно сделать в одно запросе Update
или нужно писать триггер или процедуру?
источник

V

Valery in pgsql – PostgreSQL
Попробуйте словами, без кода объяснить как объединяются таблицы и что вы желаете получить в результате
источник

ГР

Геннадий Романов... in pgsql – PostgreSQL
date1 = max(date1, date2)
источник

🌌[

🌌El.Randir/42ᅠ [AD]... in pgsql – PostgreSQL
Если джойните по ID
То просто select max(date1, date2), и это же в инсерт.
источник

V

Valery in pgsql – PostgreSQL
Там left join
источник

ГР

Геннадий Романов... in pgsql – PostgreSQL
может все-таки update а не insert?
мне нужно пересчитать все date1

мля таймер реально мешает отвечать, как-то неверно настроен

"у, я бы сделал через вложенный запрос, но это ресурсо затратно"

ну так вот я о чем я не хочу чтобы для каждого значения создавался left join
а чтобы разом заджонить и обновить все date1 которые изменились
источник