Re: hashed subplan 5000x slower than two sequential operations - Mailing list pgsql-performance
From | Bryce Nesbitt |
---|---|
Subject | Re: hashed subplan 5000x slower than two sequential operations |
Date | |
Msg-id | 4CFFEB39.1010601@obviously.com Whole thread Raw |
In response to | Re: hashed subplan 5000x slower than two sequential operations ("Marc Mamin" <M.Mamin@intershop.de>) |
List | pgsql-performance |
<tt>Marc Mamin wrote:</tt><blockquote cite="mid:C4DAC901169B624F933534A26ED7DF3103E915FA@JENMAIL01.ad.intershop.net" type="cite"></blockquote><tt><br/></tt><p><tt><font size="2">Hello,<br /> are the table freshly analyzed, with a sufficientdefault_statistics_target ?<br /></font></tt><tt><br /> autovacuum = on # Enable autovacuumsubprocess? 'on' <br /> autovacuum_naptime = 5min # time between autovacuum runs<br /> default_statistics_target= 150 # range 1-1000<br /><br /><br /></tt><blockquote cite="mid:C4DAC901169B624F933534A26ED7DF3103E915FA@JENMAIL01.ad.intershop.net"type="cite"><p><tt><font size="2"><br /> Youmay try to get a better plan while rewriting the query as an UNION to get rid of the OR clause.<br /> Something like (nottested):<br /></font></tt></blockquote><tt>It is way better<br /><br /><br /> EXPLAIN ANALYZE SELECT contexts.context_key<br/> FROM contexts<br /> JOIN articles<br /> ON (articles.context_key=contexts.context_key)<br/> WHERE (contexts.parent_key = 392210) <br /> AND articles.indexed<br /><br /> UNION<br /> SELECTcollection_data.context_key<br /> FROM collection_data<br /> JOIN articles ON (articles.context_key=collection_data.context_key)<br/> WHERE collection_data.collection_context_key = 392210<br /> AND articles.indexed;<br/><br /> QUERY PLAN <br /> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br /> Unique (cost=418.50..418.61 rows=22 width=4) (actual time=0.582..0.671 rows=28 loops=1)<br /> -> Sort (cost=418.50..418.55rows=22 width=4) (actual time=0.579..0.608 rows=28 loops=1)<br /> Sort Key: contexts.context_key<br/> Sort Method: quicksort Memory: 26kB<br /> -> Append (cost=0.00..418.01rows=22 width=4) (actual time=0.042..0.524 rows=28 loops=1)<br /> -> Nested Loop (cost=0.00..376.46rows=19 width=4) (actual time=0.040..0.423 rows=28 loops=1)<br /> -> Index Scanusing parent_key_idx on contexts (cost=0.00..115.20 rows=58 width=4) (actual time=0.021..0.082 rows=28 loops=1)<br /> Index Cond: (parent_key = 392210)<br /> -> Index Scan using article_key_idxon articles (cost=0.00..4.49 rows=1 width=4) (actual time=0.007..0.008 rows=1 loops=28)<br /> Index Cond: (public.articles.context_key = contexts.context_key)<br /> Filter: public.articles.indexed<br /> -> Nested Loop (cost=0.00..41.32 rows=3width=4) (actual time=0.043..0.043 rows=0 loops=1)<br /> -> Index Scan using collection_data_context_key_indexon collection_data (cost=0.00..14.30 rows=6 width=4) (actual time=0.012..0.015 rows=3 loops=1)<br/> Index Cond: (collection_context_key = 392210)<br /> -> Index Scan using article_key_idx on articles (cost=0.00..4.49 rows=1 width=4) (actual time=0.006..0.006 rows=0 loops=3)<br/> Index Cond: (public.articles.context_key = collection_data.context_key)<br /> Filter: public.articles.indexed<br /> Total runtime: 0.812 ms<br /><br /><br /><br /></tt>
pgsql-performance by date: