Hello,
On Wed, Oct 02, 2019 at 06:55:55PM +1300, David Sickmiller wrote:
> Last weekend I started playing with the code, but it looks like I may need
> to upgrade to an SSD to get a reasonable build time.
Did you try -jN argument to make, where N is about 2x number of cpus..
> For Zone B I
Thanks so much for looking into this!
Last weekend I started playing with the code, but it looks like I may need
to upgrade to an SSD to get a reasonable build time.
For Zone B I was imagining there would be a way to try increasingly large
jumps, perhaps aided by an index cursor that remembered
Hi Sergey!
Actually fetching min & max value for each keys (key1=1 and key2=2 in your
case) should not cost much?
Then you can compute the overlap zone (Zone B in your graph) and directly
perform a jump on the beginning of Zone B and stop at the end of Zone B instead
of EOF, using the index
Hello David,
On Mon, Sep 16, 2019 at 09:07:09PM +1200, David Sickmiller wrote:
> I've been using MySQL/MariaDB for two decades but have more recently been
> working with Elasticsearch. I knew to expect an inverted index to speed up
> querying full text fields, but I've been surprised (and a bit
Hi!
I've been using MySQL/MariaDB for two decades but have more recently been
working with Elasticsearch. I knew to expect an inverted index to speed up
querying full text fields, but I've been surprised (and a bit annoyed) at
how fast ES can query structured data. (In my case, I'm largely
5 matches
Mail list logo
