Александр Юнцевич будет жить. Поприветствуем!

Насколько разнится производительность при обновлении значения одного столбца в ряду и обновление нескольких значений в ряду?

Вопрос вытекает из того, как вообще Postgres обновляет данные, перезаписывает целый ряд, либо же отдельные байты

Посгрес версионник - он при апдейте всегда создаёт новую версию.

Создаёт новый ряд

никита - так же важно индексированные ли столбцы, и настройки влияющие на heap-only tuple

т.е. новая запись всего ряда будет но производительность зависит от некоторых других условий

Спасибо!

Саша Кобра будет жить. Поприветствуем!

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

Настюшка будет жить. Поприветствуем!

Жизнерадостно

скажите, а почему может не использоваться покрывающий индекс в довольно простом случае: create index on t(a,b,c,d,e); select a,b,c,d,e from t where a in (сотня значений)

потому что например селективность у вас по полю а совсем никакая

есть индекс чисто по полю a, и он в этом запросе используется. а так там в среднем 5 строк на уникальное значение ключа

а впрочем analyze помог. правда, ничего не ускорилось :/

Поэтому другой вопрос - почему с покрывающим индексом получилось не быстрее? Explain пишет 7k heap fetches (на 20k записей), на другой машине такая же база и там 0 heap fetches и запрос работает быстро, но там и памяти больше и нагрузка меньше. Может можно что-то подтюнить на первой машине?

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

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

SELECT DISTINCT не работает чт ото

нужно сделать выборку и убрать одинаковые ид

GROUP BY помог спс

скажите, а почему может не использоваться покрывающий индекс в довольно простом случае: create index on t(a,b,c,d,e); select a,b,c,d,e from t where a in (сотня значений)

Сколько процентов записей этой таблицы попадает под это условие?

а впрочем analyze помог. правда, ничего не ускорилось :/

Временем нельзя мерить оптимальность запроса.

Cкажите как в SQL дату за сегодня получить ??NOW()

current_date

которое именно сегодня, начало транзакции? :)

но вообще в этом вопросе содержится ответ

now()::date ))

мне кажется ключевое слово в вопросе - дата

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

которое именно сегодня, начало транзакции? :)

день сегодня) нужно сравнивать с датой из бд

NOW() помогло)

awards.starts_at < NOW() AND awards.ends_at > NOW() так вообще норм писать?

Если дату надо, то лучше так: NOW()::DATE NOT BETWEEN awards.starts_at::DATE AND awards.ends_at::DATE

но, вообще без разницы

но, вообще без разницы

Когда есть индексы и выборка по условию существенно уменьшает объёмы получаемых данных, то приведение типов обеспечит секскан против индексскана. Совсем без разницы, да. Особенно на больших табличках.

Если дату надо, то лучше так: NOW()::DATE NOT BETWEEN awards.starts_at::DATE AND awards.ends_at::DATE

почему NOT то?

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

Ты прав, мне показалось, что там исключающий был запрос, выборка вне диапазона

Когда есть индексы и выборка по условию существенно уменьшает объёмы получаемых данных, то приведение типов обеспечит секскан против индексскана. Совсем без разницы, да. Особенно на больших табличках.

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

К тому же про индексы там ничего не уточнялось. Может там имеются индексы и для даты, кроме таймштампа?

день сегодня) нужно сравнивать с датой из бд

А какое сегодня нужно в длинной транзакции через полночь?

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

индексов нету , часовык пояса не нужны))

SELECT table1.field1 table2.field2 FROM table1 LEFT JOIN table2 ON table1.id = table2.id не выводится table2.field2

может он NULL?

SELECT table1.field1 table2.field2 FROM table1 LEFT JOIN table2 ON table1.id = table2.id не выводится table2.field2

>table1.id = table2.id точно правильное условие?

или из-за того, что запятой нет. Такие вопросы сложные .)

это пример

щас реальный запрос скину

В Postgres есть аналог легковесных транзакций Cassandra?

Если нет, то как их можно симулировать?

Что значит легковесные? Запись только на 1 сервер?

https://dbfiddle.uk/?rdbms=postgres_10&fiddle=e3fad72b446f372fb1caddbd414c9c92

Если нет, то как их можно симулировать?

У pg есть mvcc

https://dbfiddle.uk/?rdbms=postgres_10&fiddle=e3fad72b446f372fb1caddbd414c9c92

А GROUP BY там зачем? Просто, в том виде что сейчас есть, без GROUP BY все работает SELECT awards.id, awards.title, awards.starts_at, awards.ends_at, statuses.vk_id-- ВОТ ЭТО ПОЛЕ НАДО ВЫВЕСТИ FROM awards LEFT JOIN statuses ON statuses.award_id = awards.id WHERE statuses.vk_id = 96676430 AND awards.starts_at < NOW() AND awards.ends_at > NOW() ORDER BY awards.id;

А GROUP BY там зачем? Просто, в том виде что сейчас есть, без GROUP BY все работает SELECT awards.id, awards.title, awards.starts_at, awards.ends_at, statuses.vk_id-- ВОТ ЭТО ПОЛЕ НАДО ВЫВЕСТИ FROM awards LEFT JOIN statuses ON statuses.award_id = awards.id WHERE statuses.vk_id = 96676430 AND awards.starts_at < NOW() AND awards.ends_at > NOW() ORDER BY awards.id;

странно в фиддле работает но в pgadmin не работает пишет ERROR: column "awards.id" must appear in the GROUP BY clause or be used in an aggregate function LINE 1: SELECT awards.id, awards.title, awards.description, awards.f... ^

И да, вопросов больше чем ответов. В таблице awards starts_at DATE, ends_at DATE типы DATE. Но при инсерте делается '2018-08-08 19:22:00.000', '2018-11-08 19:22:00.000'. Зачем? Кроме того, возможно, если я правильно понял смысл, то все же, лучше, использовать в выборке периода >= и <= (или BETWEEN0, иначе на границах дата не попадет

И в этом случае, еще, лучше уточнять, что NOW() - это дата

И в этом случае, еще, лучше уточнять, что NOW() - это дата

спасибо поправлю

странно это всё

Ну там агрегатная функция же. Надо сделать GROUP BY 1,2,3,4,5,6,7

Но проще подсчет вынести в отдельный запрос и уже его результат вычесть

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

коллеги, если это тут не оффтопик, а кто-нибудь решал такую задачу: есть табличка в psql куда льется insert'ы 2k/min, нужно как можно быстрее (лучше в реалтайме) транслировать эти данные в elastic есть несколько вариантов как это сделать, мне хотелось бы узнать был ли у кого такой опыт?

из условий, схему клиента который данных извергает менять нельзя, он условно умеет только в psql

Был ли у кого похожий опыт? Пока склоняюсь к тригерру

имхо костылями разве что

коллеги, если это тут не оффтопик, а кто-нибудь решал такую задачу: есть табличка в psql куда льется insert'ы 2k/min, нужно как можно быстрее (лучше в реалтайме) транслировать эти данные в elastic есть несколько вариантов как это сделать, мне хотелось бы узнать был ли у кого такой опыт?

кто же льет эти данные в postgres, почему бы в два места сразу не писать?

кто же льет эти данные в postgres, почему бы в два места сразу не писать?

К сожалению изменить код или логику источника я не могу. На ум приходит поставить перед postgres какую-нибудь SQL прокси и через нее делать всю грязь

Сколько процентов записей этой таблицы попадает под это условие?

1% примерно

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

Что скажете об использовании UUID как primary key вместо bigserial?

К сожалению изменить код или логику источника я не могу. На ум приходит поставить перед postgres какую-нибудь SQL прокси и через нее делать всю грязь

ну haproxy как вариант наверно

Кроме размера uuid, есть ли еще какие то проблемы с его использванием?

Что скажете об использовании UUID как primary key вместо bigserial?

Ох, а я уж думал что в эту пятницу обойдется)))

индийский ритуал "нахуа"

Ох, а я уж думал что в эту пятницу обойдется)))

неужели частый повод для дискуссий?)

неужели частый повод для дискуссий?)

Довольно таки

ну haproxy как вариант наверно

Ну там помойму несколько вариантов. Haproxy в том числе

Я вот много инфы порыл в интернетах, но ничего конкретного я не нашел. Хотелось бы услышать опыт в бою, так сказать