Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Index: Move compound format setting to index.compound_format (old setting still supported) #463

Closed
kimchy opened this issue Oct 30, 2010 · 1 comment

Comments

@kimchy
Copy link
Member

kimchy commented Oct 30, 2010

Setting compound format setting should be set using index.compound_format (defaults to false). The old setting (index.merge.policy.use_compound_file is still supported).

@kimchy
Copy link
Member Author

kimchy commented Oct 30, 2010

Index: Move compound format setting to index.compound_format (old setting still supported), closed by 1feb43a.

medcl pushed a commit to medcl/elasticsearch that referenced this issue Jul 1, 2011
mindw pushed a commit to mindw/elasticsearch that referenced this issue Sep 5, 2022
…request elastic#463)

Initial commit for certbot DNS validation wrapper

Automate generations of certificates that are not directly associated with an
instance or ALB - currently Linode based EMS clusters.


Approved-by: Andre Sodermans
costin added a commit to costin/elasticsearch that referenced this issue Dec 19, 2022
This PR is a first step in separating the physical plan into two phases:

generic overall planning
local planning (rules that apply at the segment level - currently)
For the moment, the two phases are executed at the same stage in the
planning life-cycle; separation will occur in a future PR.

High-level a local plan is defined as the operators that occur under
the first "gather" exchange. Normally it should be under the first
exchange however the same construct is used to increase parallelism -
whether this should be the case or not is outside the scope of this PR.
The local scope means working at the segment level and thus have access
to the doc and segment id (and the rest of the goodies such as ordinals
, etc... - to be introduced at a later point).

To ease the creation of rules, the planner adds (and removes) a local
plan marker that the local rules can use to know when the plan starts.
While some rules may need to work only on the local plan
(LocalOptimizations), others need to be aware of the rest of the plan

both approaches are possible.
Thus the field extraction (which relies on the doc/segment id) is now
moved into the local rule so all the necessary data is loaded before
sending the data further upstream. It has also been modified a bit
so it projects away the metadata doc/segment id before sending the
data to the exchange as the local scope ends.

The previous splitting of certain operators (TopN, Aggregate) is now
handled by the mapper instead of rules which was too bureaucratic.
The split nature of the limit has been removed since it's not used
by the physical operators and instead a dedicated rule has been added
that checks the existence of a local limit and then adds it after
the gather phase. Same approach could be used for the TopN.

Miscellaneous:

the top-level gather has been made into a rule so that no plan
modifications occur outside the planner (looking at you OutputExec)
parameterized integration tests to take into account pragmas as the
parallelization rule can significantly affect planning which, in case of 
failures, makes it difficult to chase the issue.
tweaked the integration test due to the previous discovered issue 
around Eval (Look into unifying project/eval operators elastic#322)
some of the existing rules have been simplified a bit.
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant