Тут нет insert'а, поэтому его и нет. Там SET something = вычисление(foo_small.*)

всё что вычисляется нужно будет вычислять и в insert и в update

Напиши VIEW...

Чтобы что?

Тут нет insert'а, поэтому его и нет. Там SET something = вычисление(foo_small.*)

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

Чтобы что?

Чтобы ТО. ЧТобы не дублировать выражения.

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

Я их и не дублирую, поскольку использую upsert. Не понимаю зачем вы мне так активно продаёте разделение его на два запроса

Ну, используй...

Тоже вариант

Нутк

Спасибо

кто нибудь встречал/лечил?

версия последняя с github

версия последняя с github

а также дистрибутивная с yum.postgresql.org

Я их и не дублирую, поскольку использую upsert. Не понимаю зачем вы мне так активно продаёте разделение его на два запроса

А как вы пишите, можете запрос показать?

Есть чат по microsoft sql server?

Есть чат по microsoft sql server?

https://t.me/sqlcom

Такое же тоже было. Как лечить без понятия. Стараюсь эту тулзу вообще стороной обходить.

Такое же тоже было. Как лечить без понятия. Стараюсь эту тулзу вообще стороной обходить.

а че как использовать то

Народ, всем привет. Такой вопрос. Можно поменять тип и primary key на пустой таблице?

С текст на инт

Опечатка вышла, теперь больно...

Так если таблица пустая, то почему её просто не пересоздать?

скорее всего не пустая)

Народ, всем привет. Такой вопрос. Можно поменять тип и primary key на пустой таблице?

да хоть на непустой

alter table

А не на пустой что будет?

Как будут данные проводится?

Там миграции... Поэтому пересоздать не так просто))

Так если таблица пустая, то почему её просто не пересоздать?

Там миграции... Поэтому пересоздать не так просто))

А откуда тогда известно что там будет пусто в будущем?

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

/report

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

Ага, тестирование оно всегда нормально. А как на проде, так ой - щас мы это будем исправлять скриптом.

@Komzpa @pasha_golub выручайте

Пора уже Чугунного в админы добавить ;)

/report

?

Такое же тоже было. Как лечить без понятия. Стараюсь эту тулзу вообще стороной обходить.

если pgbadger нельзя доверять и он может соврать ровна в 2 раза, то что можно использовать?

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

аналитику делать

если pgbadger нельзя доверять и он может соврать ровна в 2 раза, то что можно использовать?

Oracle

Привет,

Подскажите, пожалуйста SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp()))::INT as lag; данный запрос на слейве показывает лаг стримовой репликации, всё нормально. Но если изменений на мастере нет никаких, то, соответственно. лаг растет. Т.е данный метод не показывает отставание. Каким запросом или методом, можно его заменить в моем случае?

Подскажите, пожалуйста SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp()))::INT as lag; данный запрос на слейве показывает лаг стримовой репликации, всё нормально. Но если изменений на мастере нет никаких, то, соответственно. лаг растет. Т.е данный метод не показывает отставание. Каким запросом или методом, можно его заменить в моем случае?

Лучше всё-таки чтото менять на мастере.

Либо измерять лаг в xid'ах а не в секундах

Либо измерять лаг в xid'ах а не в секундах

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

Либо измерять лаг в xid'ах а не в секундах

так понимаЮ .данный запрос уже будет актуален на мастер сервере

так понимаЮ .данный запрос уже будет актуален на мастер сервере

Так точно

Кто может помочь, есть 3 таблицы, images, imageinfo, imageinfo_tags -> в этой таблице хранится id тэга и id imageinfo, есть запрос - SELECT a.* FROM images_image a INNER JOIN images_imageinfo b ON (a.id = b.image_id) INNER JOIN images_imageinfo_tags c ON (b.id = c.imageinfo_id) WHERE (a.is_active = true AND c.tag_id = 165038) ORDER BY a.id DESC LIMIT 3; запрос выбирает картинки по тэгу, image и imageinfo по 1kk записей, imageinfo_tags -> 7.5kk. Запрос отрабатывает где-то за 1с, что очень долго вот explain запроса - http://dpaste.com/1V281Q2.txt Что можно сделать?

Индекс создать на tag_id

А ещё лучше (tag_id,imageinfo_id)

У кого-нибудь был опыт борьбы ? postgres[47766] general protection ip:7fd9a86e5838 sp:7ffdec1b3530 error:0 in postgres[7fd9a839d000+606000] http://ps.tmpc.ru/ae1bf1c0902b

Кто может помочь, есть 3 таблицы, images, imageinfo, imageinfo_tags -> в этой таблице хранится id тэга и id imageinfo, есть запрос - SELECT a.* FROM images_image a INNER JOIN images_imageinfo b ON (a.id = b.image_id) INNER JOIN images_imageinfo_tags c ON (b.id = c.imageinfo_id) WHERE (a.is_active = true AND c.tag_id = 165038) ORDER BY a.id DESC LIMIT 3; запрос выбирает картинки по тэгу, image и imageinfo по 1kk записей, imageinfo_tags -> 7.5kk. Запрос отрабатывает где-то за 1с, что очень долго вот explain запроса - http://dpaste.com/1V281Q2.txt Что можно сделать?

Сколько записей с таким TAG в этой таблице и сколько всего?

всего тэго 7.5 миллионов, с этим тэгом 1 запись

А ещё лучше (tag_id,imageinfo_id)

сейчас попробую

Кто может помочь, есть 3 таблицы, images, imageinfo, imageinfo_tags -> в этой таблице хранится id тэга и id imageinfo, есть запрос - SELECT a.* FROM images_image a INNER JOIN images_imageinfo b ON (a.id = b.image_id) INNER JOIN images_imageinfo_tags c ON (b.id = c.imageinfo_id) WHERE (a.is_active = true AND c.tag_id = 165038) ORDER BY a.id DESC LIMIT 3; запрос выбирает картинки по тэгу, image и imageinfo по 1kk записей, imageinfo_tags -> 7.5kk. Запрос отрабатывает где-то за 1с, что очень долго вот explain запроса - http://dpaste.com/1V281Q2.txt Что можно сделать?

У тебя там параллелизм включается. Это совсем плохо.

У тебя там параллелизм включается. Это совсем плохо.

с двойным индексом норм стало, ~130мс

спасибо

с двойным индексом норм стало, ~130мс

а нет, это я другой запрос посмотрел =)

в общем сделал так - select * from images_image where id in (SELECT a.image_id FROM "images_imageinfo" a INNER JOIN "images_imageinfo_tags" c ON (a.id = c.imageinfo_id) WHERE (c.tag_id = 165038) ORDER BY a.id DESC LIMIT 3); - вот это уже быстрее работает гораздо, 170мс. еще можно что-то сделать?

вряд ли

дай еще план

ну норм, спасибо

новый

дай еще план

http://dpaste.com/27N9GSP.txt что-то опять фигиво стало. Меня тут отвлекает ребенок не могу полностью внимание сосредоточить, может что-то упустил, но пару минут назад он выдавал 130-170мс

Посмотри у тебя по всем условиям JOIn-ов есть индексы?

У кого-нибудь был опыт борьбы ? postgres[47766] general protection ip:7fd9a86e5838 sp:7ffdec1b3530 error:0 in postgres[7fd9a839d000+606000] http://ps.tmpc.ru/ae1bf1c0902b

А core dump есть?

А core dump есть?

Вот методичка https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#Getting_a_trace_from_a_randomly_crashing_backend

А core dump есть?

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

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

Поймать core -файл, доставить debug-символы из дистрибутива. C помощью gdb посмотреть где конкретно ошибка. Дальше уже думать что делать.

Посмотри у тебя по всем условиям JOIn-ов есть индексы?

вообще не врубаюсь, сейчас по другому тэгу выбираю (там полно картинок) - отрабатывает за 0.5 мс http://dpaste.com/2CAVTVG.txt запрос - select * from images_image where id in (SELECT a.image_id FROM "images_imageinfo" a INNER JOIN "images_imageinfo_tags" c ON (a.id = c.imageinfo_id) WHERE (c.tag_id = 165038) ORDER BY a.id DESC LIMIT 3);

вообще не врубаюсь, сейчас по другому тэгу выбираю (там полно картинок) - отрабатывает за 0.5 мс http://dpaste.com/2CAVTVG.txt запрос - select * from images_image where id in (SELECT a.image_id FROM "images_imageinfo" a INNER JOIN "images_imageinfo_tags" c ON (a.id = c.imageinfo_id) WHERE (c.tag_id = 165038) ORDER BY a.id DESC LIMIT 3);

в общем этот запрос норм работает, спасибо

вообще не врубаюсь, сейчас по другому тэгу выбираю (там полно картинок) - отрабатывает за 0.5 мс http://dpaste.com/2CAVTVG.txt запрос - select * from images_image where id in (SELECT a.image_id FROM "images_imageinfo" a INNER JOIN "images_imageinfo_tags" c ON (a.id = c.imageinfo_id) WHERE (c.tag_id = 165038) ORDER BY a.id DESC LIMIT 3);

Полно картинок - это сколько ? 10 , 20 , 1000 ? попробуй перенеси условие (c.tag_id = 165038) в условия соединения таблицы

Полно картинок - это сколько ? 10 , 20 , 1000 ? попробуй перенеси условие (c.tag_id = 165038) в условия соединения таблицы

да сейчас норм работает на всех тэгах, у меня там сортировка сначала стояла по image_id - она медленно работала, по id - быстро. А сортировка мне там не нужна по сути.

Привет всем!) Подскажите пожалуйста, возможно ли такое реализовать в постгре? UPDATE fds."data" SET sdata='C:\Users\file' where id=1;

Привет всем!) Подскажите пожалуйста, возможно ли такое реализовать в постгре? UPDATE fds."data" SET sdata='C:\Users\file' where id=1;

привет! выглядит как обычный запрос, если ты не вкладываешь в него какую-то интересную семантику типа "положить в поле содержимое файла" то всё нормально

привет! выглядит как обычный запрос, если ты не вкладываешь в него какую-то интересную семантику типа "положить в поле содержимое файла" то всё нормально

Эм, как раз и надо положить в поле файл(бинарный) )

Если селектить charvar вместо integer, на сколько это тормозит запрос?

Эм, как раз и надо положить в поле файл(бинарный) )

звучит как не лучший дизайн базы (уже по c:\), но пути есть - https://www.postgresql.org/docs/10/static/lo.html

Если селектить charvar вместо integer, на сколько это тормозит запрос?

откуда предубеждение о том, что тормозит?

откуда предубеждение о том, что тормозит?

Ок. Есть ли разница в скорости?

звучит как не лучший дизайн базы (уже по c:\), но пути есть - https://www.postgresql.org/docs/10/static/lo.html

Спасибо