можно здесь что-нить сделать ? время запроса стало совсем безумное
вакуум фулл аналайз проводится еженедельно

andrei=> explain analyze select domainid FROM e_whois_1 natural left join e_domaincluster where cluster is null and statusId in (21,26,28,29,30,31) limit 2000;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..8867.11 rows=2000 width=4) (actual time=1121606.953..1121648.753 rows=2000 loops=1)
-> Merge Left Join (cost=0.00..19642301.52 rows=4430371 width=4) (actual time=1121606.947..1121636.296 rows=2000 loops=1)
Merge Cond: ("outer".domainid = "inner".domainid)
Filter: ("inner"."cluster" IS NULL)
-> Index Scan using e_whois_1_pkey on e_whois_1 (cost=0.00..19318996.75 rows=4430371 width=4) (actual time=76.557..901044.053 rows=4138019 loops=1)
Filter: ((statusid = 21) OR (statusid = 26) OR (statusid = 28) OR (statusid = 29) OR (statusid = 30) OR (statusid = 31))
-> Index Scan using e_domaincluster_pkey on e_domaincluster (cost=0.00..262429.95 rows=7074643 width=6) (actual time=44.970..171520.555 rows=6697155 loops=1)
Total runtime: 1121655.040 ms
(8 rows)

Time: 1121656.042 ms

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 1 8920 15212 32824 609308 0 0 4 1 2 1 33 6 40 21
0 1 8920 14808 32684 609844 0 0 5808 132 1456 953 17 30 0 53
0 1 8920 13668 32404 611456 0 0 6912 0 1404 626 19 37 0 44
0 1 8920 13188 31516 612820 0 0 6444 0 1323 435 18 31 0 51
1 0 8920 13188 30880 613332 0 0 7508 0 1452 764 21 42 0 36

andrei=> \d e_whois_1
Table "public.e_whois_1"
Column | Type | Modifiers
----------+----------+-----------
domainid | integer | not null
created | date |
expired | date |
statusid | smallint |
Indexes:
"e_whois_1_pkey" PRIMARY KEY, btree (domainid)

andrei=> \d e_domaincluster
Table "public.e_domaincluster"
Column | Type | Modifiers
----------+----------+-----------
domainid | integer | not null
cluster | smallint |
Indexes:
"e_domaincluster_pkey" PRIMARY KEY, btree (domainid)
"e_domaincluster_cluster_idx" btree ("cluster")
"e_domaincluster_good_clusters_idx" btree (domainid) WHERE "cluster" <> -2 AND "cluster" <> 0

смысл запроса простой - выбрать 2000 необработанных доменов. необработанные - это значит не присутствующие в кластерах.

> Одно из этих подмножеств а) или б) фактически пустое?
нет, обычно ни одного

>При этом в e_whois_1 строк с нужными statusid четыре лимона?
поставил считать, скоро опубликую

>Сколько строк будет получено, если убрать limit 2000? (Вроде бы немногим больше 2000 потому что Index Scan по таблице e_domaincluster пробежал 6,7 млн из 7,1.)
в зависимости от дня недели, бывает и 100к (раз в месяц, сегодня например)

>.e_domaincluster.cluster NOT NULL ? или может быть NULL? -в зависимости от этого вопрос
может. это left join, и если домен не обработан - то NULL, обработан - integer NOT NULL

> 3. нет ли сложного индекса по полям пк и statusId из e_whois_1? Если есть, то в каком порядке стоят поля в индексе?
хм. привёл вроде все индексы

> пополнить индексы domaincluster примерно таким idx_cluster_null ((cluster IS NULL))
сорри, здесь по идее таких нет, проще было сразу delete делать, для того-же рез-та

>нет ли желания обзавестись индексом типа (statusId,domainid), а то еще и {(statusId,domainid) WHERE statusId in (21,26,28,29,30,31)}
спасибо попробуем. там всего несколько непересекающихся множеств интересных значений.

reindex помог на порядок. теперь select делается за 90 - 112 сек

andrei=> alter table e_domaincluster alter column cluster set not null;
ALTER TABLE
Time: 13968.878 ms
andrei=> reindex table e_domaincluster;
REINDEX
Time: 112052.254 ms

andrei=> explain analyze select domainid FROM e_whois_1 natural left join e_domaincluster where cluster is null and statusId in (21,26,28,29,30,31) limit 2000;

QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..9033.11 rows=2000 width=4) (actual time=362214.515..362278.745 rows=2000 loops=1)
-> Merge Left Join (cost=0.00..20275184.41 rows=4489083 width=4) (actual time=362214.507..362266.363 rows=2000 loops=1)
Merge Cond: ("outer".domainid = "inner".domainid)
Filter: ("inner"."cluster" IS NULL)
-> Index Scan using e_whois_1_pkey on e_whois_1 (cost=0.00..19963483.07 rows=4489083 width=4) (actual time=36.164..256344.313 rows=4242019 loops=1)
Filter: ((statusid = 21) OR (statusid = 26) OR (statusid = 28) OR (statusid = 29) OR (statusid = 30) OR (statusid = 31))
-> Index Scan using e_domaincluster_pkey on e_domaincluster (cost=0.00..249569.19 rows=7244241 width=6) (actual time=18.926..67319.267 rows=6907060 loops=1)
Total runtime: 362285.027 ms
(8 rows)

> P.S.: а может объеденить эти две таблицы?
думаете стоит ?

andrei=> select count(*) from e_whois_1;
count
----------
14969966
(1 row)

Time: 48707.667 ms
andrei=> select count(*) from e_domaincluster;
count
---------
7225065
(1 row)

Time: 26755.469 ms