Телеграмм чат группы pgsql страница 12343

parrot.ru

Рейтинг популярных групп и каналов

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

групп:

каналов:

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

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

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

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

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

go.backupland.com

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

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

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

Size: a a a

pgsql – PostgreSQL

5868 membersпожаловаться на группу

2021 March 09

YS

Yaroslav Schekin in pgsql – PostgreSQL

Gonchik Tsymzhitov

Привет!

подскажите, у меня есть такой запрос, который сильно медленно отрабатывается, результат запроса 15 МБ.

explain (analyze,buffers)  SELECT OAV."ID",OAV."TEXT_VALUE" FROM public."AO_8542F1_IFJ_OBJ_ATTR_VAL" OAV JOIN public."AO_8542F1_IFJ_OBJ_ATTR" OA ON OA."ID" = OAV."OBJECT_ATTRIBUTE_ID" WHERE OA."OBJECT_TYPE_ATTRIBUTE_ID" IN (529, 10, 506, 143) ;
                                                                                   QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.57..712718.82 rows=599184 width=34) (actual time=0.474..2319.057 rows=655844 loops=1)
   Workers Planned: 4
   Workers Launched: 4
   Buffers: shared hit=3296662 read=258958
   ->  Nested Loop  (cost=0.56..651800.42 rows=149796 width=34) (actual time=0.111..2204.502 rows=131169 loops=5)
         Buffers: shared hit=3296662 read=258958
         ->  Parallel Seq Scan on "AO_8542F1_IFJ_OBJ_ATTR" oa  (cost=0.00..425675.07 rows=152918 width=8) (actual time=0.053..1049.557 rows=131169 loops=5)
               Filter: ("OBJECT_TYPE_ATTRIBUTE_ID" = ANY ('{529,10,506,143}'::integer[]))
               Rows Removed by Filter: 7888265
               Buffers: shared hit=13870 read=258958
         ->  Index Scan using index_ao_8542f1_ifj228666017 on "AO_8542F1_IFJ_OBJ_ATTR_VAL" oav  (cost=0.56..1.47 rows=1 width=42) (actual time=0.008..0.008 rows=1 loops=655844)
               Index Cond: ("OBJECT_ATTRIBUTE_ID" = oa."ID")
               Buffers: shared hit=3282792
 Planning time: 0.326 ms
 Execution time: 2340.710 ms

Подскажите куда копать ? буффера, довольно норм

Перед тем, как копаться — А Вам действительно нужно 655844 rows в результате (т.е. какой в этом смысл для клиента? Или это часть какого-то ETL и т.п.?)?

источник

11:20пожаловаться #1

s

sexst in pgsql – PostgreSQL

Gonchik Tsymzhitov

Привет!

подскажите, у меня есть такой запрос, который сильно медленно отрабатывается, результат запроса 15 МБ.

explain (analyze,buffers)  SELECT OAV."ID",OAV."TEXT_VALUE" FROM public."AO_8542F1_IFJ_OBJ_ATTR_VAL" OAV JOIN public."AO_8542F1_IFJ_OBJ_ATTR" OA ON OA."ID" = OAV."OBJECT_ATTRIBUTE_ID" WHERE OA."OBJECT_TYPE_ATTRIBUTE_ID" IN (529, 10, 506, 143) ;
                                                                                   QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.57..712718.82 rows=599184 width=34) (actual time=0.474..2319.057 rows=655844 loops=1)
   Workers Planned: 4
   Workers Launched: 4
   Buffers: shared hit=3296662 read=258958
   ->  Nested Loop  (cost=0.56..651800.42 rows=149796 width=34) (actual time=0.111..2204.502 rows=131169 loops=5)
         Buffers: shared hit=3296662 read=258958
         ->  Parallel Seq Scan on "AO_8542F1_IFJ_OBJ_ATTR" oa  (cost=0.00..425675.07 rows=152918 width=8) (actual time=0.053..1049.557 rows=131169 loops=5)
               Filter: ("OBJECT_TYPE_ATTRIBUTE_ID" = ANY ('{529,10,506,143}'::integer[]))
               Rows Removed by Filter: 7888265
               Buffers: shared hit=13870 read=258958
         ->  Index Scan using index_ao_8542f1_ifj228666017 on "AO_8542F1_IFJ_OBJ_ATTR_VAL" oav  (cost=0.56..1.47 rows=1 width=42) (actual time=0.008..0.008 rows=1 loops=655844)
               Index Cond: ("OBJECT_ATTRIBUTE_ID" = oa."ID")
               Buffers: shared hit=3282792
 Planning time: 0.326 ms
 Execution time: 2340.710 ms

Подскажите куда копать ? буффера, довольно норм

У вас, для начала, совсем чуть-чуть берется из кэша, а остальное читается с дисков.
Buffers: shared hit=13870 read=258958

источник

11:21пожаловаться #2

YS

Yaroslav Schekin in pgsql – PostgreSQL

Это другой фильтр. Вы хотите вынести условия ?. Сам подселект должен каким-то образом намикать жоину, что он дебет или кредит и нужно соединить по определенным полям)

> Сам подселект должен каким-то образом намикать жоину, что он дебет

И вот этого я не понимаю совсем.
Какой результат нужен-то? Кредит или дебет? Откуда запрос должен об этом "узнать"?

источник

11:21пожаловаться #3

s

shoxrux in pgsql – PostgreSQL

Если подселект обозначен как дебет, то должен соединяться по определенным полям с мэйном. Так же с кредитом.

источник

11:24пожаловаться #4

SG

Sergey Gr in pgsql – PostgreSQL

Gonchik Tsymzhitov

Привет!

подскажите, у меня есть такой запрос, который сильно медленно отрабатывается, результат запроса 15 МБ.

explain (analyze,buffers)  SELECT OAV."ID",OAV."TEXT_VALUE" FROM public."AO_8542F1_IFJ_OBJ_ATTR_VAL" OAV JOIN public."AO_8542F1_IFJ_OBJ_ATTR" OA ON OA."ID" = OAV."OBJECT_ATTRIBUTE_ID" WHERE OA."OBJECT_TYPE_ATTRIBUTE_ID" IN (529, 10, 506, 143) ;
                                                                                   QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.57..712718.82 rows=599184 width=34) (actual time=0.474..2319.057 rows=655844 loops=1)
   Workers Planned: 4
   Workers Launched: 4
   Buffers: shared hit=3296662 read=258958
   ->  Nested Loop  (cost=0.56..651800.42 rows=149796 width=34) (actual time=0.111..2204.502 rows=131169 loops=5)
         Buffers: shared hit=3296662 read=258958
         ->  Parallel Seq Scan on "AO_8542F1_IFJ_OBJ_ATTR" oa  (cost=0.00..425675.07 rows=152918 width=8) (actual time=0.053..1049.557 rows=131169 loops=5)
               Filter: ("OBJECT_TYPE_ATTRIBUTE_ID" = ANY ('{529,10,506,143}'::integer[]))
               Rows Removed by Filter: 7888265
               Buffers: shared hit=13870 read=258958
         ->  Index Scan using index_ao_8542f1_ifj228666017 on "AO_8542F1_IFJ_OBJ_ATTR_VAL" oav  (cost=0.56..1.47 rows=1 width=42) (actual time=0.008..0.008 rows=1 loops=655844)
               Index Cond: ("OBJECT_ATTRIBUTE_ID" = oa."ID")
               Buffers: shared hit=3282792
 Planning time: 0.326 ms
 Execution time: 2340.710 ms

Подскажите куда копать ? буффера, довольно норм

Если не ошибаюсь - read=258958 - это около 2 Gb. Вроде читать 1Gb/s с диска нормально?

источник

11:24пожаловаться #5

YS

Yaroslav Schekin in pgsql – PostgreSQL

Если подселект обозначен как дебет, то должен соединяться по определенным полям с мэйном. Так же с кредитом.

Я. Ничего. Не. Понял. :(
Как Вам "ну так напишите два подселекта, какие проблемы?!" в качестве ответа? ;(

источник

11:31пожаловаться #6

GT

Gonchik Tsymzhitov in pgsql – PostgreSQL

Если не ошибаюсь - read=258958 - это около 2 Gb. Вроде читать 1Gb/s с диска нормально?

спасибо!

источник

11:31пожаловаться #7

s

sexst in pgsql – PostgreSQL

Если не ошибаюсь - read=258958 - это около 2 Gb. Вроде читать 1Gb/s с диска нормально?

Если диск не ssd, да ещё и другим вводом-выводом нагружен, то всё может быть сильно грустнее.
Я бы попробовал сделать индекс на OA(OBJECT_TYPE_AtTRIBUTE_ID, ID). Можно и без ID, но его наличие в индексе по идее может позволить сделать index only scan, без обращения к самой таблице за значениями в поле ID

источник

11:32пожаловаться #8

GT

Gonchik Tsymzhitov in pgsql – PostgreSQL

Если диск не ssd, да ещё и другим вводом-выводом нагружен, то всё может быть сильно грустнее.
Я бы попробовал сделать индекс на OA(OBJECT_TYPE_AtTRIBUTE_ID, ID). Можно и без ID, но его наличие в индексе по идее может позволить сделать index only scan, без обращения к самой таблице за значениями в поле ID

диски ssd, насчет iops на уровне виртуалки только одна базулька, но ниже на уровне вирт. инфраструктуры не уверен сколько

источник

11:33пожаловаться #9

GT

Gonchik Tsymzhitov in pgsql – PostgreSQL

Насчет индекса, пойду сделаю

источник

11:34пожаловаться #10

s

shoxrux in pgsql – PostgreSQL

Yaroslav Schekin

Я. Ничего. Не. Понял. :(
Как Вам "ну так напишите два подселекта, какие проблемы?!" в качестве ответа? ;(

Ну я написал бы 2 подселекта, но инфа по этим проводкам лежат в мэйн таблице. Мэйн таблица содержит account_id по которому я смогу соединить. А если подселект у меня дебет, то я должен вывести инфу с мэйна через account_id = cl_debet.

Например:
Есть одна проводка(транзакция) и в ней хранится счёт получателя(кредит) и отправителя(дебет). Если мне нужно информация по этой проводке по кредиту, то я должен соединить с мэйном.

Мэйн таблица - account_id

Таблица которая содержит проводки table_2 ------ А в ней есть cl_debet, cl_kredit, которые дают понять, какой счёт дебет, а какой кредит
:)

источник

11:42пожаловаться #11

GT

Gonchik Tsymzhitov in pgsql – PostgreSQL

Gonchik Tsymzhitov

Насчет индекса, пойду сделаю

# \d "AO_8542F1_IFJ_OBJ_ATTR";
                                   Table "public.AO_8542F1_IFJ_OBJ_ATTR"
          Column          |  Type   |                               Modifiers
--------------------------+---------+-----------------------------------------------------------------------
 ID                       | bigint  | not null default nextval('"AO_8542F1_IFJ_OBJ_ATTR_ID_seq"'::regclass)
 OBJECT_ID                | integer |
 OBJECT_TYPE_ATTRIBUTE_ID | integer |
 UPDATED                  | bigint  |
Indexes:
    "AO_8542F1_IFJ_OBJ_ATTR_pkey" PRIMARY KEY, btree ("ID")
    "index_ao_8542f1_ifj268009346" btree ("OBJECT_TYPE_ATTRIBUTE_ID")
    "index_ao_8542f1_ifj43488772" btree ("OBJECT_ID")
Foreign-key constraints:
    "fk_ao_8542f1_ifj_obj_attr_object_id" FOREIGN KEY ("OBJECT_ID") REFERENCES "AO_8542F1_IFJ_OBJ"("ID")
    "fk_ao_8542f1_ifj_obj_attr_object_type_attribute_id" FOREIGN KEY ("OBJECT_TYPE_ATTRIBUTE_ID") REFERENCES "AO_8542F1_IFJ_OBJ_TYPE_ATTR"("ID")
Referenced by:
    TABLE ""AO_8542F1_IFJ_OBJ_ATTR_VAL"" CONSTRAINT "fk_ao_8542f1_ifj_obj_attr_val_object_attribute_id" FOREIGN KEY ("OBJECT_ATTRIBUTE_ID") REFERENCES "AO_8542F1_IFJ_OBJ_ATTR"("ID")

источник

11:45пожаловаться #12

YS

Yaroslav Schekin in pgsql – PostgreSQL

Ну я написал бы 2 подселекта, но инфа по этим проводкам лежат в мэйн таблице. Мэйн таблица содержит account_id по которому я смогу соединить. А если подселект у меня дебет, то я должен вывести инфу с мэйна через account_id = cl_debet.

Например:
Есть одна проводка(транзакция) и в ней хранится счёт получателя(кредит) и отправителя(дебет). Если мне нужно информация по этой проводке по кредиту, то я должен соединить с мэйном.

Мэйн таблица - account_id

Таблица которая содержит проводки table_2 ------ А в ней есть cl_debet, cl_kredit, которые дают понять, какой счёт дебет, а какой кредит
:)

Мне понятнее не стало, скорее наоборот. ;(
Может, кто-то ещё сможет это прочитать и объяснить нам (или мне), в чём тут задача?

источник

11:51пожаловаться #13

YS

Yaroslav Schekin in pgsql – PostgreSQL

Gonchik Tsymzhitov

# \d "AO_8542F1_IFJ_OBJ_ATTR";
                                   Table "public.AO_8542F1_IFJ_OBJ_ATTR"
          Column          |  Type   |                               Modifiers
--------------------------+---------+-----------------------------------------------------------------------
 ID                       | bigint  | not null default nextval('"AO_8542F1_IFJ_OBJ_ATTR_ID_seq"'::regclass)
 OBJECT_ID                | integer |
 OBJECT_TYPE_ATTRIBUTE_ID | integer |
 UPDATED                  | bigint  |
Indexes:
    "AO_8542F1_IFJ_OBJ_ATTR_pkey" PRIMARY KEY, btree ("ID")
    "index_ao_8542f1_ifj268009346" btree ("OBJECT_TYPE_ATTRIBUTE_ID")
    "index_ao_8542f1_ifj43488772" btree ("OBJECT_ID")
Foreign-key constraints:
    "fk_ao_8542f1_ifj_obj_attr_object_id" FOREIGN KEY ("OBJECT_ID") REFERENCES "AO_8542F1_IFJ_OBJ"("ID")
    "fk_ao_8542f1_ifj_obj_attr_object_type_attribute_id" FOREIGN KEY ("OBJECT_TYPE_ATTRIBUTE_ID") REFERENCES "AO_8542F1_IFJ_OBJ_TYPE_ATTR"("ID")
Referenced by:
    TABLE ""AO_8542F1_IFJ_OBJ_ATTR_VAL"" CONSTRAINT "fk_ao_8542f1_ifj_obj_attr_val_object_attribute_id" FOREIGN KEY ("OBJECT_ATTRIBUTE_ID") REFERENCES "AO_8542F1_IFJ_OBJ_ATTR"("ID")

А почему индекс без id? И всё-таки любопытно, нужен ли именно этот запрос вообще (зачем столько выходных данных)...

источник

11:53пожаловаться #14

GT

Gonchik Tsymzhitov in pgsql – PostgreSQL

Yaroslav Schekin

А почему индекс без id? И всё-таки любопытно, нужен ли именно этот запрос вообще (зачем столько выходных данных)...

да, запрос нужен, к сожалению именно, этот сделан сторонними разработчиками

источник

11:55пожаловаться #15

YS

Yaroslav Schekin in pgsql – PostgreSQL

Gonchik Tsymzhitov

да, запрос нужен, к сожалению именно, этот сделан сторонними разработчиками

Тогда, в самом деле, создайте тот индекс, который подсказали, и посмотрите, что получится.

источник

11:57пожаловаться #16

s

sexst in pgsql – PostgreSQL

Gonchik Tsymzhitov

# \d "AO_8542F1_IFJ_OBJ_ATTR";
                                   Table "public.AO_8542F1_IFJ_OBJ_ATTR"
          Column          |  Type   |                               Modifiers
--------------------------+---------+-----------------------------------------------------------------------
 ID                       | bigint  | not null default nextval('"AO_8542F1_IFJ_OBJ_ATTR_ID_seq"'::regclass)
 OBJECT_ID                | integer |
 OBJECT_TYPE_ATTRIBUTE_ID | integer |
 UPDATED                  | bigint  |
Indexes:
    "AO_8542F1_IFJ_OBJ_ATTR_pkey" PRIMARY KEY, btree ("ID")
    "index_ao_8542f1_ifj268009346" btree ("OBJECT_TYPE_ATTRIBUTE_ID")
    "index_ao_8542f1_ifj43488772" btree ("OBJECT_ID")
Foreign-key constraints:
    "fk_ao_8542f1_ifj_obj_attr_object_id" FOREIGN KEY ("OBJECT_ID") REFERENCES "AO_8542F1_IFJ_OBJ"("ID")
    "fk_ao_8542f1_ifj_obj_attr_object_type_attribute_id" FOREIGN KEY ("OBJECT_TYPE_ATTRIBUTE_ID") REFERENCES "AO_8542F1_IFJ_OBJ_TYPE_ATTR"("ID")
Referenced by:
    TABLE ""AO_8542F1_IFJ_OBJ_ATTR_VAL"" CONSTRAINT "fk_ao_8542f1_ifj_obj_attr_val_object_attribute_id" FOREIGN KEY ("OBJECT_ATTRIBUTE_ID") REFERENCES "AO_8542F1_IFJ_OBJ_ATTR"("ID")

Главное чтобы в visibility map лазить не пришлось, но есть смутное ощущение что вряд ли таблица постоянно переписывается и можно index only scan таки получить.

Ну или оперативки докинуть хотя бы нужно, потому что 1049 секунд на полную выборку из таблицы, притом с 95% чтения с диска это прямо место явной боли.

источник

12:02пожаловаться #17

s

sexst in pgsql – PostgreSQL

Так что да, попробуйте, не взлетит - удалите и все дела.

источник

12:03пожаловаться #18

BR

Bot Razraba in pgsql – PostgreSQL

Привет, подскажите
У нас есть таблица с Тикетами и таблица с Рейтингами. У одного тикета может быть только один рейтинг. Один рейтинг может использоваться в нескольких тикетах. Это связь OneToOne или OneToMany?

источник

12:14пожаловаться #19

DG

Denis Girko ☕️ in pgsql – PostgreSQL

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

Привет, получилось вчера?

источник

12:17пожаловаться #20