0

i have two table . news table have 7m record and news_publish table have 70m record when i execute this query took enormous amounts of time and very slow . i add three index for tuning but query is slow. when i google this problem i found that someone suggest that change statistics to 1000 and i chage it ,but problem is yet

alter table khb_news alter submitteddate set statistics 1000;

SELECT  n.id as newsid ,n.title,p.submitteddate as publishdate,
    n.summary ,n.smallImageid  ,
    n.classification ,n.submitteddate as newsdate,
    p.toorganizationid

from  khb_news  n  
     join   khb_news_publish p    
        on n.id=p.newsid    
    left join dataitem b on b.id=n.classification 

where  
    n.classification in (1) and  n.newstype=60  
    AND n.submitteddate    >= '2014/06/01'::timestamp AND   n.submitteddate <'2014/08/01'::timestamp and p.toorganizationid=123123
order by p.id desc

limit 10 offset 0

indexes is :

CREATE INDEX "p.id"
ON khb_news_publish
USING btree
(id DESC);

CREATE INDEX idx_toorganization
ON khb_news_publish
USING btree
(toorganizationid);


CREATE INDEX "idx_n.classification_n.newstype_n.submitteddate"
ON khb_news
USING btree
(classification, newstype, submitteddate);

after add this indexes and run explain analyze i get this explain

"Limit  (cost=0.99..10100.13 rows=10 width=284) (actual time=24711.831..24712.849 rows=10 loops=1)"
        "  ->  Nested Loop  (cost=0.99..5946373.12 rows=5888 width=284) (actual time=24711.827..24712.837 rows=10 loops=1)"
        "        ->  Index Scan using "p.id" on khb_news_publish p  (cost=0.56..4748906.31 rows=380294 width=32) (actual time=2.068..23338.731 rows=194209 loops=1)"
        "              Filter: (toorganizationid = 95607)"
        "              Rows Removed by Filter: 36333074"
        "        ->  Index Scan using khb_news_pkey on khb_news n  (cost=0.43..3.14 rows=1 width=260) (actual time=0.006..0.006 rows=0 loops=194209)"
        "              Index Cond: (id = p.newsid)"
        "              Filter: ((submitteddate >= '2014-06-01 00:00:00'::timestamp without time zone) AND (submitteddate < '2014-08-01 00:00:00'::timestamp without time zone) AND (newstype = 60) AND (classification = ANY ('{19,20,21}'::bigint[])))"
        "              Rows Removed by Filter: 1"
        "Planning time: 3.871 ms"
        "Execution time: 24712.982 ms"

i add explain in https://explain.depesz.com/s/Gym how can change query to make it faster ??

ali akbar azizkhani
  • 2,213
  • 5
  • 31
  • 48
  • Please fix the explain formatting so it would work with tools like https://explain.depesz.com – Jakub Kania May 15 '16 at 10:32
  • i change it i added explain in https://explain.depesz.com/s/Gym – ali akbar azizkhani May 15 '16 at 10:40
  • `CREATE INDEX "p.id" ON khb_news_publish USING btree (id DESC);` IMHO this should have been a Primary Key (which would enforce a **UNIQUE** index). Similar for the other tables: start by constraining PK+FKs, than add supporting indexes for the FK, than add unique indexes for the othe candidate keys, than *maybe* add some addtional indexes to support your typical queries. – wildplasser May 15 '16 at 14:25

1 Answers1

2

You should start with creating an index on khb_news_publish(toorganizationid, id)

CREATE INDEX idx_toorganization_id
ON khb_news_publish
USING btree
(toorganizationid, id);

This should fix the problem but you might also need index:

CREATE INDEX idx_id_classification_newstype_submitteddate
ON khb_news
USING btree
(classification, newstype, submitteddate, id);
Jakub Kania
  • 15,665
  • 2
  • 37
  • 47
  • i have index in khb_news that have three column is drop this index and add idx_id_classification_newstype_submitteddate? or add this – ali akbar azizkhani May 15 '16 at 11:11
  • @aliakbarazizkhani Too many indexes are not a problem, at least while you're searching for an answer. And the query is 10 times faster, I think that's an improvment? – Jakub Kania May 16 '16 at 06:42