Re: [PERFORM] Joins and DELETE FROM
Thank you for your post. I finally spent some quality time with the query planner section in the docs' server config chapter. Very instructive, even considering that most of it went over my head! On Sat, Mar 8, 2008 at 4:08 PM, Tom Lane [EMAIL PROTECTED] wrote: ...have you got effective_cache_size set to something that's realistic for your machine? I guess not. It was the default value (128MB) on a machine with 4GB of RAM. It's not a dedicated server, though, so I'll set it to 1G for now. But before doing so I need a clarification. The docs state that this parameter is used only for cost estimation, and has no effect on actual memory allocations. I imagine that if other memory-related settings are not somehow in line with it, it could lead to estimates that are out of touch with reality. If this is correct what other memory-related parameters do I need to adjust to ensure that both the planner's estimates and the actual execution agree and fit well with the available memory? One problem with this test is that your smaller tables probably fit in memory whereas the big ones may not, so it's not a given that your test accurately reflects how the real query will go down. That's a very helpful reminder. Thanks. Kynn
Re: [PERFORM] Joins and DELETE FROM
Kynn Jones [EMAIL PROTECTED] writes: So it seems like turning off ENABLE_SEQSCAN is the way to go. Try reducing random_page_cost a bit instead. Also, have you got effective_cache_size set to something that's realistic for your machine? One problem with this test is that your smaller tables probably fit in memory whereas the big ones may not, so it's not a given that your test accurately reflects how the real query will go down. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Joins and DELETE FROM
Kynn Jones wrote: my_db= SET ENABLE_SEQSCAN TO OFF; my_db= EXPLAIN ANALYZE SELECT * FROM T NATURAL JOIN B; QUERY PLAN --- Merge Join (cost=0.00..423589.69 rows=219784 width=13) (actual time= 0.114..5449.808 rows=219784 loops=1) Merge Cond: (t.k = b.k) - Index Scan using idx__t on t (cost=0.00..386463.71 rows=10509456 width=13) (actual time=0.059..3083.182 rows=10509414 loops=1) - Index Scan using idx__b on b (cost=0.00..8105.04 rows=219784 width=12) (actual time=0.044..69.659 rows=219784 loops=1) Total runtime: 5473.812 ms (5 rows) That's more like 2% of the rows, not 0.1%. Note that this still isn't the plan you were asking for, it's still scanning the whole index for t, not just looking up the keys from b. What you wanted is a nested loop join. You could try to turn enable_mergejoin=off as well if you want to coerce the planner even more... -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
