В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

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

qwarta.ru подробнее

Size: a a a

pgsql – PostgreSQL

4929 membersпожаловаться на группу
2020 August 21

YS

Yaroslav Schekin in pgsql – PostgreSQL
И вот здесь оценка [очень] плохая, хотя условие простое:
->  Bitmap Index Scan on csco_idesind_2008_2020_datadate_gvkey_idx  (cost=0.00..4705.91 rows=184935 width=0) (actual time=264.946..264.947 rows=4789440 loops=1)
  Index Cond: ((datadate >= '2013-10-01 00:00:00'::timestamp without time zone) AND (datadate <= '2015-04-01 00:00:00'::timestamp without time zone))

Estimated rows=184935 против actual rows=4789440. Вы VACUUM ANALYZE (или просто ANALYZE, хотя бы) этих таблиц давно выполняли?
Остальное завтра, наверное (если время будет). ;)
источник
01:55пожаловаться#1

K

Kosta in pgsql – PostgreSQL
Yaroslav Schekin
И вот здесь оценка [очень] плохая, хотя условие простое:
->  Bitmap Index Scan on csco_idesind_2008_2020_datadate_gvkey_idx  (cost=0.00..4705.91 rows=184935 width=0) (actual time=264.946..264.947 rows=4789440 loops=1)
  Index Cond: ((datadate >= '2013-10-01 00:00:00'::timestamp without time zone) AND (datadate <= '2015-04-01 00:00:00'::timestamp without time zone))

Estimated rows=184935 против actual rows=4789440. Вы VACUUM ANALYZE (или просто ANALYZE, хотя бы) этих таблиц давно выполняли?
Остальное завтра, наверное (если время будет). ;)
ни разу. два дня как реплицированы из внешней бд
источник
01:57пожаловаться#2

K

Kosta in pgsql – PostgreSQL
спасибо!
источник
01:57пожаловаться#3

K

Kosta in pgsql – PostgreSQL
Yaroslav Schekin
Хмм... и план у Вас как-то криво вставился, смотрите:
 ->  Bitmap Heap Scan on csco_idesind_2008_2020 k  (cost=4751.48..435630.83 rows=182259 width=58) (actual time=429.871..22110.220 rows=95206 loops=1)
               Recheck Cond: ((datadate >= '2013-10-01 00:00:00'::timestamp without time zone) AND (datadate <= '2015-04-01 00:00:00'::timestamp without time zone))
               Filter: (gvkey = ANY <skip>)
               Rows Removed by Filter: 4694234
               Heap Blocks: exact=30692
               Buffers: local read=49047
               ->  Bitmap Index Scan on csco_idesind_2008_2020_datadate_gvkey_idx  (cost=0.00..4705.91 rows=184935 width=0) (actual time=264.946..264.947 rows=4789440 loops=1)
                     Index Cond: ((datadate >= '2013-10-01 00:00:00'::timestamp without time zone) AND (datadate <= '2015-04-01 00:00:00'::timestamp without time zone))
         Buffers: local read=49047
         ->  Bitmap Heap Scan on csco_idesind_2008_2020 k  (cost=4751.48..435630.83 rows=182259 width=58) (actual time=429.871..22110.220 rows=95206 loops=1)
               Recheck Cond: ((datadate >= '2013-10-01 00:00:00'::timestamp without time zone) AND (datadate <= '2015-04-01 00:00:00'::timestamp without time zone))
               Filter: (gvkey = ANY <skip>))
               Rows Removed by Filter: 4694234

Узел Bitmap Heap Scan явно задвоен и т.п. Как-то "промахнулись", когда план копировали?
да промахнулся.

https://gist.github.com/k0nsta/c517d10c3792de9c15d73a96cbfe07d1
Gist
explain-tmp-table
explain-tmp-table. GitHub Gist: instantly share code, notes, and snippets.
источник
02:12пожаловаться#4

qq

qq qq in pgsql – PostgreSQL
всем привет, подскажите как кинуть dblink к ораклу?
источник
07:29пожаловаться#5

KK

Konstantin Knizhnik in pgsql – PostgreSQL
qq qq
всем привет, подскажите как кинуть dblink к ораклу?
никак. dblink - это связь между постгресами. А с Ораклом можно работать через oracle_fdw.
источник
09:43пожаловаться#6

KK

Konstantin Knizhnik in pgsql – PostgreSQL
suchimauz
Вообщем несколько потоков должны ускорить твою задачу, попробуй
Если кому интересно. Я тут как раз недавно проводил эксперименты о том, стоит ли делать COPY в несколько потоков.
К тому же хотелось понять насколько соответствует истине общераспространённое убеждение, что в таблицу без индексов Постгрес вставляет примерно с линейной скоростью записи на диск.

Если у вас обычный HDD, то делать вставку в несколько потоков категорически противопоказано. HDD очень не любит случайных чтений/записей - для этого приходится перемещать головку, а это медленно (10мсек).
Так что параллелизм имеет смысл только на крутом RAID девайсе или SSD/NVME. Я тестировал на своё ноуте с достаточно шустрой NVME. fsync-и не выключал. Исходный CSV файл был порядка 2Gb (он полностью прокэшировался), индексов не было. Вот что я получил:
1. Средняя скоросnь вставки ~100Mb/sec. iotop показывал максимум 250Mb/sec
2. При параллельном COPY (4 потока -  я использовал патч с коммитфеста) скорость возрастает до 115Mb/sec
3. При записи в tmpfs скорость однопоточного COPY возрастает до 200Mb/sec, 4 потока - 350Mb/src
4. Замена CSV формата на binary формат практически ничего не даёт

Какой из этого можно сделать вывод? Да, COPY упирается в скорость диска. Хотя результат получается сильно медленнее, чем можно было бы ожидать исходя из ТТХ устройства. Возможно это из-за двойной записи (в WAL и в базу).
При этом даже на NVME параллелизм заметного прироста скорости не даёт.
источник
10:01пожаловаться#7

ВК

Виталий Кухарик... in pgsql – PostgreSQL
Благодарю за оценку, коллеги)
источник
10:03пожаловаться#8

AS

Alexey Stavrov in pgsql – PostgreSQL
Konstantin Knizhnik
Если кому интересно. Я тут как раз недавно проводил эксперименты о том, стоит ли делать COPY в несколько потоков.
К тому же хотелось понять насколько соответствует истине общераспространённое убеждение, что в таблицу без индексов Постгрес вставляет примерно с линейной скоростью записи на диск.

Если у вас обычный HDD, то делать вставку в несколько потоков категорически противопоказано. HDD очень не любит случайных чтений/записей - для этого приходится перемещать головку, а это медленно (10мсек).
Так что параллелизм имеет смысл только на крутом RAID девайсе или SSD/NVME. Я тестировал на своё ноуте с достаточно шустрой NVME. fsync-и не выключал. Исходный CSV файл был порядка 2Gb (он полностью прокэшировался), индексов не было. Вот что я получил:
1. Средняя скоросnь вставки ~100Mb/sec. iotop показывал максимум 250Mb/sec
2. При параллельном COPY (4 потока -  я использовал патч с коммитфеста) скорость возрастает до 115Mb/sec
3. При записи в tmpfs скорость однопоточного COPY возрастает до 200Mb/sec, 4 потока - 350Mb/src
4. Замена CSV формата на binary формат практически ничего не даёт

Какой из этого можно сделать вывод? Да, COPY упирается в скорость диска. Хотя результат получается сильно медленнее, чем можно было бы ожидать исходя из ТТХ устройства. Возможно это из-за двойной записи (в WAL и в базу).
При этом даже на NVME параллелизм заметного прироста скорости не даёт.
Спасибо, интересно.

Ещё бы посмотреть, на разницу однопоточного COPY с io_uring
источник
10:12пожаловаться#9

ST

Sardorkhuja Tukhtakh... in pgsql – PostgreSQL
Всем привет! Ребят, подскажите, пожалуйста, почему может не добавляться поле в JSON-объект?

Пишу такой код на PHP:

$username = 'str';
$obj = json_decode($db['smth']);
$obj->{'smth'} = time();
$query = "
UPDATE table
SET obj='" . json_encode($obj) . "'" .
"where username='" . $username . "'";


// тут выполняю запрос методом класса

метод, выполняющий запрос работает. Также в $query у меня есть и другие поля, они успешно обновляются.

Код можно посмотреть на SOF, если так удобнее
Stack Overflow
How to add field into JSON in PostgreSQL
I have a problem, my PostgreSQL query doesn't update one of fields.
Simplified logic (PHP with SQL):
$username = 'str';
$obj = json_decode($db['smth']);
$obj->{'smth'} = time();
$query = "
...
источник
10:23пожаловаться#10

AS

Alexey Stavrov in pgsql – PostgreSQL
Sardorkhuja Tukhtakhodjaev
Всем привет! Ребят, подскажите, пожалуйста, почему может не добавляться поле в JSON-объект?

Пишу такой код на PHP:

$username = 'str';
$obj = json_decode($db['smth']);
$obj->{'smth'} = time();
$query = "
UPDATE table
SET obj='" . json_encode($obj) . "'" .
"where username='" . $username . "'";


// тут выполняю запрос методом класса

метод, выполняющий запрос работает. Также в $query у меня есть и другие поля, они успешно обновляются.

Код можно посмотреть на SOF, если так удобнее
Stack Overflow
How to add field into JSON in PostgreSQL
I have a problem, my PostgreSQL query doesn't update one of fields.
Simplified logic (PHP with SQL):
$username = 'str';
$obj = json_decode($db['smth']);
$obj->{'smth'} = time();
$query = "
...
И каким образом сериализцется (в строку конвертируется) объект php в данном случае?
источник
10:31пожаловаться#11

ST

Sardorkhuja Tukhtakh... in pgsql – PostgreSQL
Alexey Stavrov
И каким образом сериализцется (в строку конвертируется) объект php в данном случае?
так, прошу прощения, забыл тут показать. json_encode($obj)
источник
10:32пожаловаться#12

AS

Alexey Stavrov in pgsql – PostgreSQL
Ага.
Покажите \d table на всякй случай
источник
10:32пожаловаться#13

ST

Sardorkhuja Tukhtakh... in pgsql – PostgreSQL
Alexey Stavrov
Ага.
Покажите \d table на всякй случай
details json NOT NULL DEFAULT '{}'::json

details - это $obj из примера. Упрощал, чтобы было нагляднее
источник
10:36пожаловаться#14

AS

Alexey Stavrov in pgsql – PostgreSQL
Тогда распечатайте объект $obj. который подставляете в set-е.
источник
10:37пожаловаться#15

VV

Vasily Vologdin in pgsql – PostgreSQL
Добрый день!
как написать запрос на удаление строк таблицы с условием на существование таблицы?
Нужно чтобы не возникакло ошибки если таблицы не существует уже

,те что то типа   IF EXISTS table DELETE FROM  table
источник
10:38пожаловаться#16

ST

Sardorkhuja Tukhtakh... in pgsql – PostgreSQL
Alexey Stavrov
Тогда распечатайте объект $obj. который подставляете в set-е.
выходит такой формат:

obj='{"smth":1597991609}'

у obj изначально есть и другие поля, тут указал только новое, которое как раз и не добавляется
источник
10:40пожаловаться#17

AS

Alexey Stavrov in pgsql – PostgreSQL
А что возрвращает операция update?
источник
10:40пожаловаться#18

AS

Alexey Stavrov in pgsql – PostgreSQL
Vasily Vologdin
Добрый день!
как написать запрос на удаление строк таблицы с условием на существование таблицы?
Нужно чтобы не возникакло ошибки если таблицы не существует уже

,те что то типа   IF EXISTS table DELETE FROM  table
Одним запросом, видимо, никак.
источник
10:41пожаловаться#19

s

suchimauz in pgsql – PostgreSQL
Konstantin Knizhnik
Если кому интересно. Я тут как раз недавно проводил эксперименты о том, стоит ли делать COPY в несколько потоков.
К тому же хотелось понять насколько соответствует истине общераспространённое убеждение, что в таблицу без индексов Постгрес вставляет примерно с линейной скоростью записи на диск.

Если у вас обычный HDD, то делать вставку в несколько потоков категорически противопоказано. HDD очень не любит случайных чтений/записей - для этого приходится перемещать головку, а это медленно (10мсек).
Так что параллелизм имеет смысл только на крутом RAID девайсе или SSD/NVME. Я тестировал на своё ноуте с достаточно шустрой NVME. fsync-и не выключал. Исходный CSV файл был порядка 2Gb (он полностью прокэшировался), индексов не было. Вот что я получил:
1. Средняя скоросnь вставки ~100Mb/sec. iotop показывал максимум 250Mb/sec
2. При параллельном COPY (4 потока -  я использовал патч с коммитфеста) скорость возрастает до 115Mb/sec
3. При записи в tmpfs скорость однопоточного COPY возрастает до 200Mb/sec, 4 потока - 350Mb/src
4. Замена CSV формата на binary формат практически ничего не даёт

Какой из этого можно сделать вывод? Да, COPY упирается в скорость диска. Хотя результат получается сильно медленнее, чем можно было бы ожидать исходя из ТТХ устройства. Возможно это из-за двойной записи (в WAL и в базу).
При этом даже на NVME параллелизм заметного прироста скорости не даёт.
Да, из-за записи WAL
источник
10:41пожаловаться#20