-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Optimize API: Allow to optimize index/indices #9
Comments
Optimize API: Allow to optimize index/indices. Closed by cfafb52. |
is this the correct usage for the options?
ta clint |
Yes, except that the boolean parameters expect true, and not 1. Ohh wait, just pushed support for 1 as well for http parameters to indicate true :) |
By the way, I think I am also going to add support to provide all this parameters in the body of the request as a JSON (instead in the query string), what do you think? |
about you added support for true / 1 - please can you do that for the JSON as well. For instance:
re adding the params to the JSON instead: yes, that would make sense to me - for a wrapper like ElasticSearch.pm, it makes little difference having the params in one place or the other - it'd probably be easier to just deal with the JSON. |
Added support for 0 to represent false in all places where I parse JSON or http parameters. Will work later on getting support for JSON body as well. |
Hiya Just had another thought about this:
One request that wouldn't work so well is:
because the entire JSON document represents the document being indexed, so slipping opType=create in there wouldn't work clint |
Yes, I am referring currently only to requests that don't have a body. The one mentioned as the index/delete/create and search operations do not fall into this category. I need to think what a solution (if needed) for them will be. |
pom update for new version
* Remove electionValueForced * Replace believed-unnecessary check with an assertion
…t minor version
…ons_hook_commit Hook commit and replay ops.
Fixes elastic/elasticsearch-internal#497 Fixes ESQL-560 A query like `from test | sort data | limit 2 | project count` fails because `LocalToGlobalLimitAndTopNExec` planning rule adds a collecting `TopNExec` after last GATHER exchange, to perform last reduce, see ``` TopNExec[[Order[data{f}#6,ASC,LAST]],2[INTEGER]] \_ExchangeExec[GATHER,SINGLE_DISTRIBUTION] \_ProjectExec[[count{f}#4]] // <- `data` is projected away but still used by the TopN node above \_FieldExtractExec[count{f}#4] \_TopNExec[[Order[data{f}#6,ASC,LAST]],2[INTEGER]] \_FieldExtractExec[data{f}#6] \_ExchangeExec[REPARTITION,FIXED_ARBITRARY_DISTRIBUTION] \_EsQueryExec[test], query[][_doc_id{f}#9, _segment_id{f}#10, _shard_id{f}#11] ``` Unfortunately, at that stage the inputs needed by the TopNExec could have been projected away by a ProjectExec, so they could be no longer available. This PR adapts the plan as follows: - add all the projections used by the `TopNExec` to the existing `ProjectExec`, so that they are available when needed - add another ProjectExec on top of the plan, to project away the originally removed projections and preserve the query semantics This approach is a bit dangerous, because it bypasses the mechanism of input/output resolution and validation that happens on the logical plan. The alternative would be to do this manipulation on the logical plan, but it's probably hard to do, because there is no concept of Exchange at that level.
With this commit we embed Kibana dashboards for nightly and release benchmarks. As we want to gather further feedback we did not yet remove the old functionality based on dygraphs (this will happen in elastic#33). Closes elastic#23 Closes elastic#9 Closes elastic#11 Closes elastic#12
Provide the ability to optimize an index or indices down to a provided number of segments.
The text was updated successfully, but these errors were encountered: