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

Optimize API: Allow to optimize index/indices #9

Closed
kimchy opened this issue Feb 14, 2010 · 8 comments
Closed

Optimize API: Allow to optimize index/indices #9

kimchy opened this issue Feb 14, 2010 · 8 comments

Comments

@kimchy
Copy link
Member

kimchy commented Feb 14, 2010

Provide the ability to optimize an index or indices down to a provided number of segments.

@kimchy
Copy link
Member Author

kimchy commented Feb 14, 2010

Optimize API: Allow to optimize index/indices. Closed by cfafb52.

@clintongormley
Copy link
Contributor

is this the correct usage for the options?

curl -XPOST http://127.0.0.2:9200/_optimize?onlyExpungeDeletes=1&flush=1&refresh=1

ta

clint

@kimchy
Copy link
Member Author

kimchy commented Feb 18, 2010

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 :)

@kimchy
Copy link
Member Author

kimchy commented Feb 18, 2010

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?

@clintongormley
Copy link
Contributor

about you added support for true / 1 - please can you do that for the JSON as well. For instance:

{ query: {
        filteredQuery: {
                query: {............},
                explain: true      # should accept 1 here as well
}}

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.

@kimchy
Copy link
Member Author

kimchy commented Feb 20, 2010

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.

@clintongormley
Copy link
Contributor

Hiya

Just had another thought about this:

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?"

One request that wouldn't work so well is:

curl -XPUT 'http://127.0.0.2:9200/es_test/type_1/1?opType=create'  -d '
{
   "num" : 2,
   "text" : "foo"
}
'

because the entire JSON document represents the document being indexed, so slipping opType=create in there wouldn't work

clint

@kimchy
Copy link
Member Author

kimchy commented Feb 20, 2010

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.

kimchy added a commit that referenced this issue Jun 5, 2015
dadoonet added a commit that referenced this issue Jun 5, 2015
dadoonet added a commit that referenced this issue Jun 5, 2015
dadoonet added a commit that referenced this issue Jun 5, 2015
Seen in #9, Google changed its APIs. We need to update as it previous version causes a `404` error.

Closes #12.
Closes #9.
dadoonet added a commit that referenced this issue Jun 9, 2015
dadoonet added a commit that referenced this issue Jun 9, 2015
With #2784, we can now add plugin version in `es-plugin.properties` file.

It will only be used with elasticsearch 1.0.0 and upper. No need to push it in 1.x branch.

Closes #9.
rahulanishetty referenced this issue in rahulanishetty/elasticsearch Jan 19, 2017
ywelsch pushed a commit to ywelsch/elasticsearch that referenced this issue Dec 21, 2017
* Remove electionValueForced
* Replace believed-unnecessary check with an assertion
ClaudioMFreitas pushed a commit to ClaudioMFreitas/elasticsearch-1 that referenced this issue Nov 12, 2019
fcofdez pushed a commit to fcofdez/elasticsearch that referenced this issue Nov 19, 2021
…ons_hook_commit

Hook commit and replay ops.
ChrisHegarty pushed a commit that referenced this issue Aug 9, 2023
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.
cbuescher pushed a commit to cbuescher/elasticsearch that referenced this issue Oct 2, 2023
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
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

2 participants