# Different execution plans for the same query on two separate installations **URL:** \ **Category:** Uncategorized\ **Created:** [February 20, 2019, 2:35pm UTC](https://community.dremio.com/t/different-execution-plans-for-the-same-query-on-two-separate-installations/2808 "2019-02-20T14:35:41Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![oliver](https://avatars.discourse-cdn.com/v4/letter/o/85f322/32.png) [@oliver](https://community.dremio.com/u/oliver)\ **Post date:** [February 20, 2019, 2:35pm UTC](https://community.dremio.com/t/different-execution-plans-for-the-same-query-on-two-separate-installations/2808/1 "2019-02-20T14:35:41Z")
Hi, I’m running the same query on two separate dremio installations ( **same version, same configuration** ) with very different results concerning execution time. On neither system the query gets accelarated. The query is a simple select with predicates: ```auto select * from table where column_a=foo and column_b=bar ``` **On System A:** The query gets pushed down to the database basically as is. Execution takes about 2 minutes. **On System B:** The query that gets pushed down to the database looks like this: ```auto select * from table ``` Rows in the result set that do not match the predicates seem to be eliminated later. Execution takes about 20 minutes, that is 10 times longer. Can you help me understand how this is happening and also is there a way to force the behavior of system a for system b? I’ve attached the query profiles: [system\_a.zip](https://us1.discourse-cdn.com/flex020/uploads/dremio/original/2X/c/cc80fb4b53ae647dd1c65c350e42ba7fc6f4a5eb.zip) (17,5 KB) [system\_b.zip](https://us1.discourse-cdn.com/flex020/uploads/dremio/original/2X/a/a7e95a5fbcb6e6410a84eee48eca8cf951f6a857.zip) (15,0 KB) ---
**Author:** ![kelly](https://sea2.discourse-cdn.com/flex020/user_avatar/community.dremio.com/kelly/32/11_2.png) [@kelly](https://community.dremio.com/u/kelly)\ **Post date:** [February 20, 2019, 8:06pm UTC](https://community.dremio.com/t/different-execution-plans-for-the-same-query-on-two-separate-installations/2808/2 "2019-02-20T20:06:17Z")
Which version of Dremio? What is the data source? Is your reflection store set up the same way on both? ---
**Author:** ![ben](https://sea2.discourse-cdn.com/flex020/user_avatar/community.dremio.com/ben/32/1367_2.png) [@ben](https://community.dremio.com/u/ben)\ **Post date:** [February 20, 2019, 9:11pm UTC](https://community.dremio.com/t/different-execution-plans-for-the-same-query-on-two-separate-installations/2808/3 "2019-02-20T21:11:57Z")
Hi @oliver What kind of source is `bdb`? Is there any difference between the way you have configured that source between the the two Dremio installs? I do see that you have reflections enabled on `bdb.public.dokument_neu` in the environment where the filters are pushdown, but not the other. These reflections are note matched, however. We may be able to understand better if you enable verbose profiles. In each Dremio environment, can you go to Admin --\> Support and add and enable the following parameter: `planner.verbose_profile` Please rerun the query on each system and attach the results here. ---
**Author:** ![oliver](https://avatars.discourse-cdn.com/v4/letter/o/85f322/32.png) [@oliver](https://community.dremio.com/u/oliver)\ **Post date:** [February 21, 2019, 8:21am UTC](https://community.dremio.com/t/different-execution-plans-for-the-same-query-on-two-separate-installations/2808/4 "2019-02-21T08:21:44Z")
@kelly @ben dremio version: “3.1.1-201901281837360699-30c9d74” source: postgresql data source configuration including reflection store setup is the same on both systems @ben I configured the data source the same way on both environments. There is an aggregate reflection in one environment but it is not used by the query in question. I already tried building the same reflection on the other environment but it did not change the execution plan. Query profiles with `planner.verbose_profile` enabled: [system\_a\_verbose.zip](https://us1.discourse-cdn.com/flex020/uploads/dremio/original/2X/d/d86a91650620eaac6dc01dc5bfb5ba4ab5d4ac00.zip) (20,7 KB) [system\_b\_verbose.zip](https://us1.discourse-cdn.com/flex020/uploads/dremio/original/2X/e/e1a6a7e27235c9a4620bcea50a193e9a7fd4b008.zip) (18,0 KB) ---
**Author:** ![ben](https://sea2.discourse-cdn.com/flex020/user_avatar/community.dremio.com/ben/32/1367_2.png) [@ben](https://community.dremio.com/u/ben)\ **Post date:** [February 26, 2019, 3:47am UTC](https://community.dremio.com/t/different-execution-plans-for-the-same-query-on-two-separate-installations/2808/5 "2019-02-26T03:47:00Z")
This is perplexing, @oliver, because it appears that both queries initially cost the Postgres scan in the same way, so there’s not an obvious reason why one system would plan for the pushdown while the other would choose a filter in Dremio. The profiles indicate that there is 1 difference between the two Dremio configurations, namely, `results.max.age_in_days` is set to 3 in the profile of the query with pushdown. I have no reason to believe this would affect the planning, but you could try making every support parameter exactly the same between the instances. You could also try disabling the reflections in instance without the pushdown. Perhaps that is affecting the planning path in a manner that is not recorded in the profile. Is there any other difference you can think of between these 2 systems? ---
**Author:** ![oliver](https://avatars.discourse-cdn.com/v4/letter/o/85f322/32.png) [@oliver](https://community.dremio.com/u/oliver)\ **Post date:** [March 6, 2019, 3:30pm UTC](https://community.dremio.com/t/different-execution-plans-for-the-same-query-on-two-separate-installations/2808/6 "2019-03-06T15:30:16Z")
> Is there any other difference you can think of between these 2 systems? I really missed a difference. On the environment where the query gets pushed down `Enable legacy dialect` is checked in the advanced options of the postgresql data source. Checking this option on environment B will result in the query getting pushed down to the database just as on environment A. Thank you for your help.