Re: osdl-dbt3 run results - puzzled by the execution plans
От | Matt Clark |
---|---|
Тема | Re: osdl-dbt3 run results - puzzled by the execution plans |
Дата | |
Msg-id | LFEIJBEOKGPDHCEMDGNFOEEKCDAA.matt@ymogen.net обсуждение исходный текст |
Ответ на | osdl-dbt3 run results - puzzled by the execution plans (Jenny Zhang <jenny@osdl.org>) |
Ответы |
Re: osdl-dbt3 run results - puzzled by the execution
|
Список | pgsql-performance |
> We thought the large effective_cache_size should lead us to better > plans. But we found the opposite. Maybe it's inappropriate for little old me to jump in here, but the plan isn't usually that important compared to the actual runtime. The links you give show the output of 'explain' but not 'explain analyze', so it's not clear wich plan is actually _faster_. If you really do have only 8MB of FS cache, then either plan will run slowly. If you really do have 5GB of FS cache then either plan will run a lot faster. Why would you deliberately give the planner false information about this? PG obviously thinks plan 1 is 'better' when pages have to be fetched from disk, and plan 2 is 'better' when they don't. Which is really better depends on whether those pages do have to be fetched from disk or not, and PG can only know what you tell it about that, so changing ECS without actually removing the RAM from the system seems a little pointless to me... M
В списке pgsql-performance по дате отправления: