From: Konstantin Osipov <kostja@tarantool.org>
To: tarantool-patches@freelists.org
Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Subject: [tarantool-patches] Re: [PATCH 1/2] space: add method to fetch next rowid
Date: Wed, 21 Nov 2018 21:58:42 +0300 [thread overview]
Message-ID: <20181121185842.GG18547@chai> (raw)
In-Reply-To: <C7337190-86D3-44B2-AC0A-259592E564E3@tarantool.org>
* n.pettik <korablev@tarantool.org> [18/11/12 16:12]:
>
> It is true that 2^64 is likely to be quite huge number of tuples,
> but for instance JOIN uses nested-loop algorithm, so it requires
> n^2 memory for ephemeral table to comprise results.
> In this regard, to reach the limit we need 4-way join where each
> table contains 2^16 entries, which in turn doesn’t seem to be giant.
>
> *It is only thoughts tho, I haven’t tested it since I suppose very likely
> my pc would simply get stuck.*
intel 64 bit architecture can not address more than 48 bits.
Apart from the fact that you can multiply 4 numbers in a cross
join there is a question how much time this nested loop is going
to run. Imagine it runs 2^48 processor ticks. It's several weeks
by a conservative estimate.
>
> I wanted to create long test as the easiest solution, but Alexander warned
> me that Travis may not survive such test due to lack of memory.
>
>
--
Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
http://tarantool.io - www.twitter.com/kostja_osipov
next prev parent reply other threads:[~2018-11-21 18:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-29 19:02 [tarantool-patches] [PATCH 0/2] Re-implement rowid generation for ephemeral spaces Nikita Pettik
2018-10-29 19:02 ` [tarantool-patches] [PATCH 1/2] space: add method to fetch next rowid Nikita Pettik
2018-10-30 8:45 ` Vladimir Davydov
2018-10-30 10:32 ` n.pettik
2018-11-09 9:25 ` [tarantool-patches] " Vladislav Shpilevoy
2018-11-11 23:16 ` n.pettik
2018-11-11 23:22 ` Vladislav Shpilevoy
2018-11-14 23:11 ` n.pettik
2018-11-21 18:58 ` Konstantin Osipov [this message]
2018-10-29 19:02 ` [tarantool-patches] [PATCH 2/2] sql: use vtab::rowid_next() instead of index_max() Nikita Pettik
2018-11-09 9:25 ` [tarantool-patches] " Vladislav Shpilevoy
2018-11-15 4:54 ` [tarantool-patches] Re: [PATCH 0/2] Re-implement rowid generation for ephemeral spaces Kirill Yukhin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181121185842.GG18547@chai \
--to=kostja@tarantool.org \
--cc=tarantool-patches@freelists.org \
--cc=v.shpilevoy@tarantool.org \
--subject='[tarantool-patches] Re: [PATCH 1/2] space: add method to fetch next rowid' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox