powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / JOIN с большой таблицей
2 сообщений из 2, страница 1 из 1
JOIN с большой таблицей
    #39048454
Demonuka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В общем есть большая таблица (40 млн записей).
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
CREATE TABLE bd.details
(
  id serial NOT NULL,
  manid integer NOT NULL,
  pweight double precision,
  plength double precision,
  pwidth double precision, 
  phigh double precision, 
  pnidrating integer,
  partno character varying(20) NOT NULL, 
  weightrating integer,
  countryid integer DEFAULT 0,
  CONSTRAINT pk_maincat PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE bd.details
  OWNER TO postgres;

CREATE UNIQUE INDEX idx_det_1_man_part
  ON bd.details
  USING btree
  (manid, partno COLLATE pg_catalog."default");


Это что то вроде справочника и SELECT по данной таблице выполняется либо по первичному ключу (id), либо по паре значений уникального индекса (manid, partno). Так вот если просто делать SELECT, типа
Код: plsql
1.
SELECT * FROM "bd"."details" WHERE "details"."id" = 1001


То все хорошо и быстро (примерно 11ms). Но если использовать таблицу в JOIN, то время выполнения - адский ад. Например запрос
Код: plsql
1.
2.
3.
4.
5.
SELECT * 
FROM   "bd"."ordertab" AS "Extent1"
       JOIN "bd"."details" AS "Extent2"
         ON "Extent1"."pnid" = "Extent2"."id"
WHERE "Extent1"."orderid" = 164


Возвращает 1 строку за 5962 ms!!! У меня есть стойкое ощущение, что это ненормально. Но что с этим делать - неясно. VACUUM и REINDEX делал. Больше в таблице исправлять нечего. Backup -> Restore тоже делал - не помогло. План и анализ выдали вот это:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
"Merge Join  (cost=1.92..1.98 rows=1 width=172) (actual time=6464.726..6464.728 rows=1 loops=1)"
"  Merge Cond: ("Extent2".id = "Extent1".pnid)"
"  ->  Index Scan using pk_maincat on details "Extent2"  (cost=0.56..1770536.37 rows=37769472 width=62) (actual time=0.014..4879.081 rows=27123967 loops=1)"
"  ->  Sort  (cost=1.35..1.35 rows=1 width=110) (actual time=0.045..0.045 rows=1 loops=1)"
"        Sort Key: "Extent1".pnid"
"        Sort Method: quicksort  Memory: 25kB"
"        ->  Seq Scan on inordertab "Extent1"  (cost=0.00..1.34 rows=1 width=110) (actual time=0.026..0.030 rows=1 loops=1)"
"              Filter: (id = 164)"
"              Rows Removed by Filter: 26"
"Planning time: 0.543 ms"
"Execution time: 6464.827 ms"


Как видно из лога почти все время заняла именно операция JOIN. В общем не знаю, что с этим делать и прошу помощи! ))
...
Рейтинг: 0 / 0
JOIN с большой таблицей
    #39048485
Demonuka
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Demonuka, в общем проблема решена. Что это было я не знаю, но VACUUM по всей базе помог..))
...
Рейтинг: 0 / 0
2 сообщений из 2, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / JOIN с большой таблицей
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]