gt; + if (left_expr->fix_fields(thd, _expr))
> + {
> +res= TRUE;
> +goto out;
> + }
> + left_expr_orig= left_expr;
> + is_correlated= will_be_correlated;
> + /* Update any Item_in_optimizer wrapper if exists */
> + if (optimizer)
> + {
> +optimizer-&
Hello Igor,
I'm looking at your latest patch for MDEV-26301 in bb-10.4-igor
and I see an obvious bug in the execution part:
Split-materialized table re-fill is triggered by this code in
sub_select():
if (join_tab->split_derived_to_update && !end_of_records)
{
table_map tab_map=
Hi Oleg,
Why is the call to Item::date_conds_transformer done after
prune_partitions()?
This causes partition pruning not to be able to use the conditions:
--source include/have_partition.inc
--source include/have_sequence.inc
create table t1 (
a datetime,
key(a)
) partition by
Hello Igor,
So I'm looking at the bb-10.4-release-igor tree with your latest patch:
commit c4fa6c3c4eaacefd9bf50b5c88c2c72474a15bc5 (HEAD -> bb-10.4-release-igor,
origin/bb-10.4-release-igor)
Author: Igor Babaev
Date: Tue Jan 31 13:14:53 2023 -0800
MDEV-30218 Incorrect optimization for
Hello,
Just taking notes from the optimizer call:
Check out this branch: 10.4-mdev30218-print-negative-gain (git log -3
output below)
It has:
- 10.4-release contents
- then mdev30218_bb-10.4-release.diff patch provided by Igor
- then a debug patch by me.
I run:
./mtr --mem --parallel=5 --force
Hi Rex,
Please find below input for the commit.
(I've actually committed an alternative fix now, but before doing that I wrote
all the trivial comments below so I'm sending these anyway in order to show
what is expected of a patch. I'm also including the rationale for creating
an alternative
Hi Rex,
I am looking at the latest commit:
commit 9eba044b9710bbdd8195e887cfdd4d62233942ca (HEAD ->
bb-MDEV-21092-21095-29997-optimizer-trace-updates,
Author: Rex
Date: Fri Dec 2 16:46:54 2022 +1200
MDEV-21092,MDEV-21095,MDEV-29997: Optimizer Trace for index condition pushdown,
partition
Hi Rex,
Nice to see progress with the patch, but there is further input.
In ./mysql-test/main/opt_trace.test
Do you see this comment at the end:
> --echo # End of 10.6 tests
Please move the newly added testcases to be AFTER that line.
This is important for those who do merges between version.
Hi Oleg,
> commit 4cad1e16a85114815075e5706d6a8faf5e8fc2e5
> Author: Oleg Smirnov
> Date: Wed Oct 19 13:26:19 2022 +0400
>
> MDEV-29624 MDEV-29655 Fix ASAN errors on pushdown of derived table
>
> Deallocation of TABLE_LIST::dt_handler and TABLE_LIST::pushdown_derived
> was
On Tue, Dec 07, 2021 at 07:01:45PM +0300, Sergey Petrunia wrote:
> == Issue #1: ordered index scan is not handled in ha_partition ==
I've hit this again when trying to get range optmizer to work. Please find the
patch below. It follows MySQL-8's approach.
>
> Testcase:
>
> c
Hi Serg,
There is some non-trivial input too, after all. Please find below.
> commit da2903f03de039693354176fda836e6642d6d0f0
> Author: Sergei Golubchik
> Date: Wed Nov 24 16:50:21 2021 +0100
>
> MDEV-26938 Support descending indexes internally in InnoDB (server part)
>
> *
Hi Sergei,
Please find my input below.
> diff --git a/sql/sql_select.cc b/sql/sql_select.cc
> index 0dfe95e81b0..fa07608177a 100644
> --- a/sql/sql_select.cc
> +++ b/sql/sql_select.cc
> @@ -7910,28 +7910,27 @@ best_access_path(JOIN *join,
> can make an adjustment is a
Hi Sergei,
> commit eb7d6304a2aa168e09d48f6884dadf8c9f868feb
> Author: Sergei Krivonos
> Date: Mon Nov 15 01:37:04 2021 +0200
>
>do not output empty subqueries in traces
This reads as if the trace can have an empty clause describing a subquery. This
is very confusing.
Actually, the patch
Hi Sergei,
> commit d2b4782200ccfd0850f36d25c75082974e4b86e1
> Author: Sergei Krivonos
> Date: Sun Nov 14 10:37:20 2021 +0200
>
> MDEV-27036: duplicated keys in best_access_path
>
> diff --git a/sql/sql_select.cc b/sql/sql_select.cc
> index 3272f8b7f65..29e9c0efe36 100644
> ---
Thanks!
On Tue, Nov 09, 2021 at 11:58:44AM +0200, Elena Stepanova wrote:
> Hi Sergey,
>
> On 11/9/21 11:48, Sergey Petrunia wrote:
> > Hi Elena,
> >
> > The patch for https://jira.mariadb.org/browse/MDEV-26929 has been merged
> > from
> > 10.4 into all
Hi Elena,
The patch for https://jira.mariadb.org/browse/MDEV-26929 has been merged from
10.4 into all versions up to 10.8.
Could you enable the optimizer trace run in the buildbot please?
BR
Sergei
--
Sergei Petrunia, Software Developer
MariaDB Corporation | Skype: sergefp | Blog:
e to
force-push into the branch after that).
I think this is all the input, and the patch will be ready for pushing once all
of this is addressed.
> > Item #2: please improve the commit comment as was requested in my previous
> > e-mail:
> >
> > On Thu, Oct 28, 2021 at
previous
e-mail:
On Thu, Oct 28, 2021 at 04:58:35PM +0300, Sergey Petrunia wrote:
> First, input on the commit comment. Please consider it as a request applying
> to ALL further commits to the MariaDB codebase.
>
>
> > MDEV-23766: implemented requested debug checks
>
>
Hi Serg,
Ok the patch moving in the right direction but it's not there, yet.
Please find the input below.
First, input on the commit comment. Please consider it as a request applying
to ALL further commits to the MariaDB codebase.
> MDEV-23766: implemented requested debug checks
Imagine
t;
> Intel Corporation | intel.com
>
>
> -Original Message-
> From: Sergey Petrunia
> Sent: Wednesday, July 14, 2021 2:26 AM
> To: Berrocal, Eduardo
> Cc: Sergei Golubchik ; maria-developers@lists.launchpad.net
> Subject: Re: [Maria-developers] Accessing read re
Hi Eduardo,
On Mon, Jul 12, 2021 at 11:30:35PM +, Berrocal, Eduardo wrote:
> "A question: do you intend to push down and check conditions in arbitrary
> form?
> In case they are just equalities, it might make sense for storage engine
> to pretend having an index and then Batched Key
Hi Eduardo,
On Thu, Jul 08, 2021 at 06:43:05PM +, Berrocal, Eduardo wrote:
> I have tried to use that route but without success. The problem is that I can
> only access the last record read from table1.
>
Yes, this is expected.
> Let say that, during the JOIN, 3 rows are read from
Hi Alexey,
> On Sun, May 30, 2021 at 06:44:19AM +0400, Alexey Botchkov wrote:
> > Hi, Sergey!
> >
> > I meditated about it for some time. I remember i was thinking on that part
> > before and
> > did that so for some reason. Though either i was wrong or didn't finish
> > what i planned.
> > This
Hi Alexey,
This is review input re
https://github.com/MariaDB/server/commit/02469bdead5753eccb5d70c98a158a07027f4eb2.
First, our workflow dictates that this patch should have its own MDEV entry.
I've filed it https://jira.mariadb.org/browse/MDEV-25875.
Please use it in commit descriptions.
==
Just to clarify: we are looking at two options currently.
Please find their description below.
== Current mysql.column_stats ==
Currently, MariaDB defines mysql.column_stats as:
CREATE TABLE column_stats (
db_name varchar(64) COLLATE utf8mb3_bin NOT NULL,
table_namevarchar(64)
Best regards.
> HF
>
>
> On Wed, May 26, 2021 at 8:01 PM Sergey Petrunia wrote:
>
> > Hi Alexey,
> >
> > At the moment MariaDB requires that the values in DEFAULT clauses are
> > quoted.
> > Example:
> >
> > select *
> > from
>
Hi Alexey,
At the moment MariaDB requires that the values in DEFAULT clauses are quoted.
Example:
select *
from
json_table(
'{"intval": 1000}',
'$' columns(
col1 int path '$.intval_'
default '100' on empty
)
) as T;
here,
Hi Nikita,
On Tue, May 18, 2021 at 04:06:25PM +0300, Nikita Malyavin wrote:
>
> I am glad to present the design for IO_CACHE's SEQ_READ_APPEND mode
> concurrency improvements. Jira task is MDEV-24676.
So, this is targeting only the scenario with multiple producers and one
consumer?
I see
Hello,
There was this question raised:
Why can't JSON_TABLE code just use the current Name_resolution_context objects?
== Context ==
Name_resolution_context object has these two members that specify a subset of
tables to use:
TABLE_LIST *first_name_resolution_table;
TABLE_LIST
Hello Igor,
A followup to yesterday's discussion:
== Short ==
MySQL-8 does store JSON_TABLE's rows into a temporary table. It doesn't seem to
allow any "caching", neither when JSON_TABLE's argument depends on some table,
nor when it is independent.
== Long ==
First, construct the example
On Thu, Apr 01, 2021 at 10:14:04PM -0700, Igor Babaev wrote:
> Sergey,
>
> Can you explain this:
>
> MariaDB [test]> explain format=json select * from t1 as t2 where item_name
> in(select item_name from t2 as s, json_table(t2.item_props,'$' columns(
> color varchar(100) path '$.color')) as
Hello Igor,
with recursive cte1 as (
select *
from
t1,
json_table(t1.item_props,'$' columns( color varchar(100) path '$.color'))
as t
),
cte2 as (
select *
from
(select 1 as n from dual) x,
cte1
union all
select
cte2.n+1,
cte2.item_name,
Hello Igor,
I was looking at the example you've posted earlier this week on Slack:
Igor> @holyfoot, @spetrunia: here' serious problem with identification for
JSON_TABLEs:
create table t1 (item_name varchar(32), item_props varchar(1024));
insert into t1 values ('Laptop', '{"color": "black",
A patch for this issue:
http://lists.askmonty.org/pipermail/commits/2021-March/014500.html
I'll need to check one more thing.
On Sun, Mar 14, 2021 at 08:42:40PM +0300, Sergey Petrunia wrote:
> On Sat, Mar 13, 2021 at 04:01:56PM +0400, Alexey Botchkov wrote:
> > I've rewritten it using
On Sat, Mar 13, 2021 at 04:01:56PM +0400, Alexey Botchkov wrote:
> I've rewritten it using the json->select_lex->leaf_tables as you suggested.
> So the JSON_TABLE is calculated properly and all the dependencies seem to
> be marked.
> Still your testcase query fails the same way, so needs some more
On Sat, Mar 06, 2021 at 01:13:53AM +0400, Alexey Botchkov wrote:
> Hi, Sergei!
>
> I pushed the patch to the feature branch for you to take a look.
> The patch you proposed
> http://lists.askmonty.org/pipermail/commits/2021-March/014492.html
> I liked and adapted with one exception. The nested
Hi Alexey,
> diff --git a/sql/opt_table_elimination.cc b/sql/opt_table_elimination.cc
> index 3958797ec44..f2497d524ec 100644
> --- a/sql/opt_table_elimination.cc
> +++ b/sql/opt_table_elimination.cc
> @@ -637,6 +637,16 @@ void eliminate_tables(JOIN *join)
>List_iterator
Hi Alexey,
What does the code quoted below do? I don't recall seeing it on previous review
iterations.
In any case,
* It needs a comment about why such special handling is needed.
* It needs test coverage - I have reverted these changes and didn't see
any test to fail?
> diff --git
More input:
> --- a/sql/sql_yacc.yy
> +++ b/sql/sql_yacc.yy
> @@ -15975,6 +15976,7 @@ reserved_keyword_udt_not_param_type:
> | IF_SYM
> | IGNORE_DOMAIN_IDS_SYM
> | IGNORE_SYM
> +| IGNORED_SYM
> | INDEX_SYM
> | INFILE
> | INNER_SYM
Any
Hi Varun,
> diff --git a/sql/lex.h b/sql/lex.h
> index 542356c0e433..5a9ec2ec1b35 100644
> --- a/sql/lex.h
> +++ b/sql/lex.h
> @@ -289,6 +289,7 @@ static SYMBOL symbols[] = {
>{ "IDENTIFIED",SYM(IDENTIFIED_SYM)},
>{ "IF",SYM(IF_SYM)},
>{ "IGNORE",
Hi Alexey,
On Sat, Mar 06, 2021 at 01:13:53AM +0400, Alexey Botchkov wrote:
> Hi, Sergei!
>
> I pushed the patch to the feature branch for you to take a look.
This broke CI, please fix:
Hi Varun,
I'm still looking at MDEV-8306 code. Sending the input I have so far. There's
nothing important but I thought I'd share it now so you can address it while
I'm continuing with the review.
> propagate_equal_field_for_orderby
Please use "order_by" as in all other functions, and also
Hi Alexey,
Please find below final bits of input. After these are addressed the patch
will probably be good to push (But I'll need a final pass before giving ok to
push).
== json_table_mysql* tests ==
* Please remove one of the json_table_mysql and json_table_mysql2 tests.
* Please move the
Hi Alexey,
Please check out this patch:
http://lists.askmonty.org/pipermail/commits/2021-March/014492.html
Any objections to it?
BR
Sergei
--
Sergei Petrunia, Software Developer
MariaDB Corporation | Skype: sergefp | Blog: http://petrunia.net
Hi Alexey,
I was looking at Json_table_nested_path::set_position(), wondering why does
it have an assignment
np->m_null= TRUE;
but doesn't clear the NULL values and trying to come up with an example of this
going wrong when I've hit this crash:
select * from
json_table(
'[
{"name":
Hi Varun,
The code for the task is mostly fine. But I would like to question the user
experience.
== Ignoring an index causes InnoDB table rebuild ==
First (and foremost), making an index ignored (or not ignored) in an InnoDB
table rebuilds the table:
MariaDB [test]> set session
On Mon, Feb 22, 2021 at 09:59:54PM +0300, Sergey Petrunia wrote:
> == On table dependencies: table elimination ==
>
> create table t20 (a int not null);
> create table t21 (a int not null primary key, js varchar(100));
>
> insert into t20 values (1),(2);
> insert into t21
On Mon, Feb 22, 2021 at 09:59:54PM +0300, Sergey Petrunia wrote:
> == On table dependencies: regular subqueries ==
>
> But it doesn't work for regular subqueries either (and this is unexpected):
>
> insert into t21 values (3, '{"a":300}');
>
> explain
>
Hi Alexey,
First reactions to the JSON_TABLE patch:
== CI Build is failing ==
Please check
http://buildbot.askmonty.org/buildbot/grid?category=main=bb-10.6-mdev17399-hf
the JSON_TABLE tests are failing.
== On testcases ==
I see now the patch has tests in 3 files:
1.
On Sun, Feb 14, 2021 at 05:14:10PM +0400, Alexey Botchkov wrote:
> One question left about the json_table_mysql.text.
>
> --error ER_WRONG_OUTER_JOIN
> SELECT * FROM t1 RIGHT JOIN
> (SELECT o FROM t2, JSON_TABLE(j, '$[*]' COLUMNS (o FOR ORDINALITY)) AS jt)
> AS t3
> ON (t3.o = t1.x);
>
> What is
On Sat, Feb 13, 2021 at 03:23:50PM +0300, Sergey Petrunia wrote:
> > /* Substituting WHERE clause's field items with sort-nest's field items */
> > if (conds)
> > {
> >conds= conds->transform(thd, ::replace_with_nest_items, TRUE,
> >
Hi Varun,
I'm looking at JOIN::substitute_base_with_nest_field_items() and I have these
questions:
> /* Substituting SELECT list field items with sort-nest's field items */
> while ((item= it++))
> {
>Item *real_item= item->real_item();
> if ((new_item= real_item->transform(thd,
>
Hi Varun,
(This email is not the complete input, and not the most important part of the
input. More to follow. I think it's better to split input into multiple smaller
pieces, it's easier to track, and you get to see the first portions of the
input sooner)
EXPLAIN EXTENDED SELECT t3.b, t2.a,
Hi Alexey,
At the moment, name resolution of JSON_TABLE's first argument is done "like in
the WHERE clause" - one can refer to any table that is defined in the WHERE
clause.
This allows one to write queries where JSON_TABLE tables have incorrect
dependencies
- circular
- dependency that
On Mon, Feb 08, 2021 at 08:34:15PM +0300, Sergey Petrunia wrote:
> I see that for other tables, TABLE_LIST::dep_tables is computed in
> simplify_joins(). simplify_joins() can remove table dependencies if it
> converts an outer join into inner.
> Can it somehow remove a dependency o
Hi Alexey,
I have discovered another issue:
JSON_TABLE's dependencies are not updated after derived merge.
An example of failing query can be found below.
The problem scenario is:
* Table_function_json_table::setup() is called. It computes dep_tables.
* The derived table is merged,
On Fri, Feb 05, 2021 at 02:01:22PM +0300, Sergey Petrunia wrote:
> I've also found this:
>
> CREATE FUNCTION FN_COUNT_ROWS(X JSON)
> RETURNS INT DETERMINISTIC
> RETURN (
> SELECT COUNT(*) FROM JSON_TABLE( X, '$[*]' COLUMNS( I INT PATH '$')) der
> );
> SELECT FN_
I've also found this:
CREATE FUNCTION FN_COUNT_ROWS(X JSON)
RETURNS INT DETERMINISTIC
RETURN (
SELECT COUNT(*) FROM JSON_TABLE( X, '$[*]' COLUMNS( I INT PATH '$')) der
);
SELECT FN_COUNT_ROWS('[1, 2]') CNT;
This produces
+--+
| CNT |
+--+
|0 |
+--+
while it should produce 2.
Hi Alexey,
More input: JSON's true is converted to integer 0, not 1.
SELECT *
FROM
JSON_TABLE('{"col": true}',
'$' COLUMNS(
col1 INT PATH '$.col' ERROR ON ERROR
)
) as jt;
In MariaDB, this produces
+--+
| col1 |
+--+
|0 |
Hi Alexey,
Consider this:
select * from
json_table(
'[{"a":"asd"},
{"a":123},
{"a":[]},
{"a":{}}
]',
'$[*]'
columns (
id for ordinality,
intcol int path '$.a' default '1234' on empty default '5678' on error
)
) as tt;
+--++
| id | intcol |
== Short ==
JSON null value should be converted to SQL NULL value, but it is converted to 0
or "null" instead:
== Long ==
select * from
json_table(
'[{"a":"aa"}, {"b":null}]',
'$[*]' columns (
col1 int path '$.b' default '456' on empty
)
) as tt;
MariaDB:
+--+
| col1 |
+--+
== Short ==
I've discovered another mismatch between MariaDB implementation and MySQL.
I don't think we need to fix it.
== Long ==
select * from
json_table(
'[{"a":"aa"}, {"b":"bb"}]',
'$[*]' columns (
col1 varchar(100) path '$.b' default 'bbb' on empty
)
) as tt;
In MySQL, this
Hi Alexey,
Consider this:
select * from
json_table(
'{"a":[1,2]}',
'$' columns (
jsn_path json path '$.a' default '{}' on empty
)
) as tt;
MySQL produces:
+--+
| jsn_path |
+--+
| [1, 2] |
+--+
MariaDB produces:
+--+
| jsn_path |
+--+
|
Hi Alexey,
On Fri, Jan 29, 2021 at 10:42:59AM +0400, Alexey Botchkov wrote:
> Some updates were pushed.
> See here for the review.
> https://github.com/MariaDB/server/commit/d7ff97bd1343a94430152389f90c4d08f56fce44
>
Good.
First input:
MariaDB [(none)]>
SELECT x, length(x)
FROM
Hi Varun,
Please find input below.
On Mon, Dec 28, 2020 at 02:34:40PM +0530, varun wrote:
> revision-id: cdc305c8dd89a726e09e5fe70ff890d06609cbfb
> (mariadb-10.3.21-309-gcdc305c8dd8)
> parent(s): 043bd85a574a88856ab9c6d497e682ed06fe45e9
> author: Varun Gupta
> committer: Varun Gupta
>
Hi Varun,
Please find some cosmetic input below. Ok to push after addresed.
> diff --git a/mysql-test/main/subselect4.test b/mysql-test/main/subselect4.test
> index 6f5eb1f2985f..e9da028618f6 100644
> --- a/mysql-test/main/subselect4.test
> +++ b/mysql-test/main/subselect4.test
> @@ -2238,3
Hi Alexey,
I've found this discrepancy in JSONPath evaluation:
set @json_doc3 =
'
{
"root": {
"child1" : {
"child2" : {
"child1" : {
"x":124
}
}
}
}
}
';
select json_extract(@json_doc3, '$**.child1**.x');
MariaDB [test]> select
On Mon, Nov 16, 2020 at 01:53:39PM +0300, Sergey Petrunia wrote:
> Input on the latest patch for MDEV-17399.
..
> Please find the first few cases below.
And a few more from the same source:
=== JSON_TABLE cannot depend on another one ? ===
drop table t1;
CREATE TABLE t1(id int, jd varch
Hi Alexey,
Input on the latest patch for MDEV-17399.
It's good to see the patch taking shape, but have you tried running MySQL's
tests for JSON_TABLE on it?
I did, and it has caught several crashes, as well as error-no-error
discrepancies and different query results. Some of these were
Hi Varun,
I have only cosmetic comments, please find them below.
Ok to push after they are addressed.
> The issue here was with the re-execution of a subquey, after few executions
> the subquery execution returned error that not enough space was provided
> inside the sort
> buffer.
>
Hi Varun,
> Commit 3e29c5a1620deef2fa9b25a0d42b4c07fe59e96f
>
> MDEV-21265: IN predicate conversion to IN subquery should be allowed for a
> broader set of datatype comparison
>
> Allow materialization strategy when the collation of the columns of the
> left side of the IN subquery are not same
Hello Igor,
On Mon, Oct 05, 2020 at 10:13:17PM -0700, Igor Babaev wrote:
>
> I've accepted all your changes for my original fix.
> This is a new patch for 10.2.
>
...
> diff --git a/sql/opt_range.cc b/sql/opt_range.cc
> index e933d2a..9f1fb9a 100644
> --- a/sql/opt_range.cc
> +++
Hello again,
Again, taking notes about the input of the last call.
The question raised was the interface of the Unique class.
== Before the patch ==
- Unique object stores elements of the same size.
- The size is passed in the constructor
- unique_add has the key as a parameter:
class Unique
One more thing:
On Mon, Sep 14, 2020 at 03:38:38PM +0400, Alexey Botchkov wrote:
> CREATE TABLE t1(id INT, f1 JSON);
> INSERT INTO t1 VALUES (1, '{\"1\": 1}'), (2, '{\"1\": 2}'), (3, '{\"1\":
> 3}'),
> (4, '{\"1\": 4}'), (5, '{\"1\": 5}'), (6, '{\"1\": 6}');
>
> SELECT * FROM t1 WHERE id IN
>
Hi Alexey,
On Mon, Sep 14, 2020 at 03:38:38PM +0400, Alexey Botchkov wrote:
> Hi, Sergei!.
>
> so the branch name is 'bb-mdef17399-hf'.
> It has slightly changed since last patch so please pay attention.
>
> There i present the patch that resolves issues that you mentioned
> in your last
Hello Igor,
Trying to capture the input from the last call.
Currently class Unique is using RB-Tree for its in-memory storage. RB-Tree is
implemented by struct TREE and tree_XXX() functions (further I'll refer to them
both as just "TREE").
It is possible to get Unique to use some other data
Hi Varun,
I was looking at the code for MDEV-21829, trying to understand whether there
are any issues with how Unique object was extended to handle variable-size
keys.
== TREE object (the RB tree) ==
TREE (the structure and functions that operate on it) support variable-sized
keys, however the
Hi Varun,
First: I can still get the assertion failure if I run this:
set @@sql_mode='only_full_group_by';
select min(1 mod a1), bit_or(a2) over () from t1;
As far as I understand, the query is not valid for
only_full_group_by mode. (Window functions as such are ok,
but here window function
Hi Alexey,
More input:
== Circular dependencies are allowed ==
This query will cause an assert in the optimizer, for obvious reasons:
select *
from
json_table(JS3.size, '$' columns (size INT PATH '$.size')) as JS1,
json_table(JS1.size, '$' columns (size INT PATH '$.size')) as JS2,
Hi Alexey,
Did you try running MySQL's test?
It needs some adjustments to run, but these can be done. I've found four
crashes:
--echo #
--echo # Bug#26500384: ASSERT FAILURE IN QUERY WITH WINDOW FUNCTION AND
--echo # JSON_TABLE
--echo #
--disable_parsing
## psergey: crash!
CREATE
Hi Alexey,
On Thu, Jul 16, 2020 at 04:34:46PM +0400, Alexey Botchkov wrote:
>
> In the new patch i think i addressed most of your comments.
> https://github.com/MariaDB/server/commit/d3a311a8e9508ef94dddb6b7f4d366337a9fd64a
>
...
> > The above doesn't do proper quoting, which is wrong.
Hi Alexey and everyone,
I was looking at whether it's possible use JSON_TABLE to extract portions of
JSON
document. Apparently it is possible in MySQL with JSON datatype:
Q1:
select *
from
json_table('[{"color": "blue", "price": { "high": 10, "low": 5}},
{"color": "red",
Hi Alexey,
> revision-id: 0d342ab173cdbf5d35c5f2833c66b6004b9e908e
> (mariadb-10.5.2-330-g0d342ab173c)
> parent(s): b1ab211dee599eabd9a5b886fafa3adea29ae041
> author: Alexey Botchkov
> committer: Alexey Botchkov
> timestamp: 2020-06-08 14:51:04 +0400
> message:
>
> MDEV-17399 Add support for
Hi Varun,
Please find some minor comments below. Ok to push when addressed.
> revision-id: 97e932919bd53b854e0cea0d0001d185d7e63cc0
> (mariadb-10.4.11-199-g97e932919bd)
> parent(s): 0a5668f5128c731a346abf41afdc6fed33164ffc
> author: Varun Gupta
> committer: Varun Gupta
> timestamp: 2020-05-26
Hi Varun,
I only have input about comments/variable names. Please find it below.
On Tue, Mar 24, 2020 at 10:14:38AM +0530, Varun wrote:
> revision-id: 4f528bb514c607d848b30119cea135e37e0d9c69
> (mariadb-10.5.0-425-g4f528bb514c)
> parent(s): 1cd8e8213b6019794ca7f01e8276cfd1ba6408cf
> author:
On Thu, Jun 11, 2020 at 03:41:24PM +0530, Varun Gupta wrote:
> > /*
> > pack_length() returns size (in bytes) used to store field data in
> > memory
> > (i.e. it returns the maximum size of the field in a row of the table,
> > which is located in RAM).
> > */
> > virtual uint32
Hi Varun,
> MDEV-21831: Assertion `length == pack_length()' failed in
> Field_inet6::sort_string upon INSERT into RocksDB table
>
> For INET6 columns the values are stored as BINARY columns and returned to the
> client in TEXT format.
> For rocksdb the indexes store mem-comparable images for
On Mon, Jun 08, 2020 at 04:05:48PM +0400, Alexey Botchkov wrote:
> So the problem is that we (MariaDB) doesn't consider the JSON field content
> as a JSON, but as a plain text.
> That affects not only aggregate functions, but any other expecting JSON
> arguments.
> To me it's the bug, should be
Hi Alexey,
I'm looking at how JSON_ARRAYAGG and JSON_OBJECTAGG work at processing JSON
documents.
I'm trying these examples, first on MySQL-8:
create table t30 (col1 json);
insert into t30 values('{"color":"red", "size":1}' );
insert into t30 values('{"color":"blue", "size":2}' );
select
Hi Varun,
> revision-id: c408c41230c4a9de0114d13aaf861d3ced65f4c7
> (mariadb-10.5.0-424-gc408c41230c)
> parent(s): 95da2113a050ad739fdaf60ee871329468a01554
> author: Varun Gupta
> committer: Varun Gupta
> timestamp: 2020-03-31 11:57:37 +0530
> message:
>
> MDEV-11563: GROUP_CONCAT(DISTINCT ...)
Hi Alexey,
Consider this example:
create table t20 (a varchar(10), b int);
insert into t20 values ('red', 1), ('blue', 2), ('red',1001), ('blue', 1002);
select json_objectagg(a,b) from t20;
+--+
| json_objectagg(a,b) |
Hi Varun,
* Please limit the commit comment to ~80 chars wide.
* The .result file has r_total_time_ms. Use analyze-format.inc to avoid
this.
Ok to push after this is addressed.
> commit 9e755e21799695b9a837a240a86ba5ef863ae7b3
> Author: Varun Gupta
> Date: Tue Jun 2 16:31:53 2020 +0530
>
Hi Varun,
Please add a comment above the declaration of Field::sort_string() that some
implementations actually may write up to 8 bytes regardless of what size was
requested.
Ok to push after that.
> revision-id: e14dcfe0bc743aa6b4ed2b3c4f7e9314aa01d6eb
> (mariadb-10.1.43-158-ge14dcfe0bc7)
>
Hi Alexey,
On Fri, May 15, 2020 at 04:26:02PM +0400, Alexey Botchkov wrote:
> See the next iteration here
> https://github.com/MariaDB/server/commit/692cb566096d61b240ec26e84fc7d3c7d13f024c
> So the ha_json_table;:position() was implemented.
> The size of the reference depends on the nested path
Hi Varun,
- Please add a testcase to the testsuite
- Please address a few cosmetic comments below
- Ok to push after addressed.
> commit 5e448b77a3812e65623c0a1214049322ace3aacf
> Author: Varun Gupta
> Date: Tue May 5 20:44:43 2020 +0530
>
> MDEV-22461: JOIN::make_aggr_tables_info():
Hi Alexey,
More review input, based on the latest code:
== It doesn't compile ==
I get the following compiler error and indeed looks the compiler complains
about a real problem there:
/home/psergey/dev-git2/10.5-hf-review/sql/item_jsonfunc.cc:340:15: error:
‘code’ may be used uninitialized in
On Sun, May 03, 2020 at 04:47:46PM +0530, Varun Gupta wrote:
> On Fri, May 1, 2020 at 2:15 AM Sergey Petrunia wrote:
> > The patch also introduces this behaviour:
> >
> > analyze table ... persistent for ... indexes(no_such_index);
> >
> > will now cause engine
Hi Varun,
On Sun, Apr 12, 2020 at 09:08:37PM +0530, Varun wrote:
> revision-id: 3ead2cea95c32b7ceaf6e6ec81f7afbd9137cfe9
> (mariadb-10.2.31-103-g3ead2cea95c)
> parent(s): d565895bbd8e2a163be48b9bac51fccbf3949c80
> author: Varun Gupta
> committer: Varun Gupta
> timestamp: 2020-04-12 21:05:36
Hello Igor,
Could you please review the below:
commit 793b100cc01228f01ead841d6c45f9e2b07786f9
Author: Sergei Petrunia
Date: Thu Apr 30 01:25:11 2020 +0300
MDEV-22377: Subquery in an [UPDATE] query uses full scan instead of range
When doing IN->EXISTS rewrite,
Hi Alexey,
Please find the next batch of input below. (I haven't finished the review but
I'm sending it now so you can start addressing it)
> commit 68ca18518337443090bdeddf6d612129b6843c21
> Author: Alexey Botchkov
> Date: Fri Apr 17 14:42:40 2020 +0400
>
> MDEV-17399 Add support for
1 - 100 of 295 matches
Mail list logo
