Re: I don't understand that EXPLAIN PLAN timings
От | Jean-Christophe Boggio |
---|---|
Тема | Re: I don't understand that EXPLAIN PLAN timings |
Дата | |
Msg-id | 61fab101-c7f1-4a88-8099-5f68bfd4f99d@thefreecat.org обсуждение исходный текст |
Ответ на | Re: I don't understand that EXPLAIN PLAN timings (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: I don't understand that EXPLAIN PLAN timings
|
Список | pgsql-performance |
David, > It would be good to narrow down which plan node is causing this. Can > you try disabling various planner enable_* GUCs before running EXPLAIN > (SUMMARY ON) <your query> with \timing on and see if you can find > which enable_* GUC causes the EXPLAIN to run more quickly? Just watch > out for variations in the timing of "Planning Time:". You're still > looking for a large portion of time not accounted for by planning > time. I put the original values for work_mem and temp_buffers back to 1GB (don't know if that made a difference in the results). Execution time is consistent at ~135ms Here are the results for planning time, disabling each planner method : enable_async_append 0.454ms *slowest enable_bitmapscan 0.221ms enable_gathermerge 0.176ms enable_hashagg 0.229ms enable_hashjoin 0.127ms enable_incremental_sort 0.143ms enable_indexonlyscan 0.147ms enable_indexscan 0.200ms enable_material 0.138ms enable_memoize 0.152ms enable_mergejoin 0.122ms*fastest enable_nestloop 0.136ms enable_parallel_append 0.147ms enable_parallel_hash 0.245ms enable_partition_pruning 0.162ms enable_seqscan 0.137ms enable_sort 0.143ms enable_tidscan 0.164ms Hope this helps. Thanks, JC
В списке pgsql-performance по дате отправления: