Hi Devs,
In line with earlier major structural refactorings of storage/index-related
code [1] I would like to propose a next step in this cleanup [2].
The main problem that I tried to solve with this patch is that code responsible
for LSM disk/memory component lifecycle (creation, destruction,
Sorry, that was a problem in my local dev version.
+1 in this case.
> On Aug 18, 2017, at 16:35, Ildar Absalyamov <ildar.absalya...@gmail.com>
> wrote:
>
> -1
>
> Source artifacts:
> - Verified signatures and hashes
> - Verified LICENSE and NOTICE
> - Verified
should assume that the type of this field is completely open,
i.e., {}, and pass it down the chain.
> On Jul 14, 2017, at 00:09, Ildar Absalyamov <ildar.absalya...@gmail.com>
> wrote:
>
> Taewoo,
>
> You’ve correctly identified the issue here: to make use of an enforc
Taewoo,
You’ve correctly identified the issue here: to make use of an enforced index we
must cast the record to a particular type, which is imposed by the index.
So, using your example, if we have an index on path “nested.one.title” the
indexed record must be castable to {…, “nested”:
Maybe I missed something, but how nested access on a closed type without a
proper nested field is ever valid?
create type CSXType as closed {id: int32}
create index title_index_CSX on CSX(nested.one.title: string?) enforced;
Will this index every be anything but empty?
for $a in
If I remember correctly we eliminated FieldAccessNested function in favor in
chained FieldAccessByName\ByIndex. @Steven, correct me if I am wrong.
> On Jun 24, 2017, at 18:00, Yingyi Bu wrote:
>
> Hi Wail,
>
>$22 should be a harmless bug -- it's related to the ordering
I found Young-Seok’s asterix-experiment package useful for everyone, who is
doing any kind of experiments.
Can we instead make an ‘asterix-contrib’ repo and move it there, the same way
we did with asterix-bad?
We can also launch an automated build in Jenkins to verify it builds against
master,
In light of Steven’s discussion about feeds in parallel thread I was wondering
what would be a correct way to push parallel ingestion as far as possible in
multinode\multipartition environment.
In one of my experiments I am trying to saturate the ingestion to see the
effect of computing stats
I believe we already support upsert feeds ;)
https://github.com/apache/asterixdb/blob/master/asterixdb/asterix-app/src/test/resources/runtimets/queries/feeds/upsert-feed/upsert-feed.1.ddl.aql
Ian,
There is an existing API, which does exactly that.
https://github.com/apache/asterixdb/blob/master/asterixdb/asterix-app/src/main/java/org/apache/asterix/api/http/server/ConnectorApiServlet.java#L123
hat could
>> also be useful in scripting more user-level-oriented recovery tests.)
>>
>> Thus, I'd likely vote for adding a harmless new DDL statement - another
>> arm of the one that supports compaction - for this.
>>
>> Cheers,
>>
>>
Hi devs,
Since I was out for quite a while and a lot of things happened in a meantime in
a codebase I wanted to clarify couple of things.
I was wondering if there is any legitimate way to force the data of in-memory
components to be flushed, other then stop the whole instance?
It used to be
As Yingyi pointed out we don't reorder joins because the framework for
stats and cardinalities is not there yet.
However what we can do in an meantime is to provide an interface for the
statistical information, needed for join reordering, independent of the way
the stats were collected (either
native support of unsigned integers.
>> Is there any database or SQL implementation supporting that?
>>
>> FYI:
>>
>> http://dba.stackexchange.com/questions/53050/why-arent-unsigned-integer-types-available-in-the-top-database-platforms
>>
>> Best,
>> Yingyi
Hi devs,
As I was generating various data distributions for statistics experiments one
thing kept bothering me.
All Asterix integer types (int8, int16, int32, int64) are signed. However
majority of real use cases does not require negative integer values. Seems like
we are waisting half of the
15 matches
Mail list logo