Sanja,
These are some general notes about the patch:
- Change Item::add_if_unique() to a method of base_list, and the List
template class.
- There is no need in subselect_engine::nest_level() because a subquery
predicate is always at the same nest level irrespective of the chosen
engine.
Sergey,
Please review the below patch. As discussed, all other
solutions that try to keep the call to mark_as_null_row()
lead to a chicken-egg-like problem that is tricky to
solve. Since I am not sure it is worth solving, I suggest
the below simple solution.
Timour
-
Igor,
Could you please review this fix for bug lp:809266.
Timour
revno: 3104
revision-id: tim...@askmonty.org-20110713211507-j9v80yk2tzae8tq2
parent: tim...@askmonty.org-20110713141146-339e3xwz17hogqsb
fixes bug(s): https://launchpad.
Igor,
Could you please review my patch for bug LP:809245.
Ttimour
Original Message
Return-Path:
X-Original-To: tim...@askmonty.org
Delivered-To: tim...@askmonty.org
Received: from localhost (localhost.localdomain [127.0.0.1])by
hasky.askmonty.org (Postfix) with ESMTP id
Sergey,
This is not a review, just a quick look at the patch.
The below solution is totally cryptic. Please add a
comment why items in the ref_array are the right ones.
If someone ever has to deal with this code, even your
commit comment (not speaking that there is no code comment)
will provide
Sergey,
In our discussion we agreed that I check why in several EXPLAINs the
value of the "rows" column changed from 1 to 0. The cause is casting.
If range optimization is blocked for those queries, then the value
of POSITION::records_read is 0.69996. This value is cast
to ha_rows in
Could you please review ASAP, as this bug blocks
RQG testing of your tree.
Timour
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More he
Sergey
Could you please review my fix for bug lp:802979.
I need you specifically because I needed to touch
the range optimzizer to disable evaluation of
single-row subqueries.
Please consider if I chose the best place in the
range optimizer to disable this evaluation of
single-row subqueries.
I
Igor,
Ok to push in the sense that the new patch cannot any more
result in overflow. Both the old and new code are not equivalent.
Given there is no comment, I cannot fully understand whether the
change produces at least as good estimate of the record length
as the old patch.
Could you please ad
Sergey,
Ok to push. I'd rather add a comment to the block of code
starting with:
" // 1. Store the length "
At least to me it was not obvious why it is the way it is.
Timour
At file:///home/psergey/dev2/5.3-push3/
revno: 3049
re
Hi Sergey,
> Hello,
>
> This is to inform you that today I've pushed MWL#90 into 5.3-main. There was a
> buildbot run on 5.3-subqueries-mwl90 tree before the push, and it did not show
> any failures that weren't also present in 5.3-main.
On one hand it is good that you pushed sooner than later,
Hi Sergey,
Hi Timour,
While merging, I also got the following questions:
== exclude_expensive_cond ==
make_cond_for_table()'s exclude_expensive_cond parameter is not used anymore.
Was it intentional that you kept it in the code?
(minimizing MWL#89's diff size could not be a reason because the
Igor,
the following bug is present in different ways both
in 5.3 and in 5.3-mwl89.
https://bugs.launchpad.net/maria/+bug/725050
The crash in 5.3-mwl89 appeared after merging with
the latest 5.3. The crash in 5.3 requires a rather
artificial example, but it shows that there is some
inconsistency
Sergey,
I only suggest to change the comment so that it says that
loose scan can process only range conditions, not that it
cannot process SEL_TREEs with type=SEL_ARG::MAYBE_KEY.
Ok to push.
Timour
Hi Timour,
Could you please review the below? (Asking you because the fix is in the loose
ind
Igor,
While merging 5.3-mwl89 with 5.3 I noticed that when you extracted
a block of code from add_key_part() into the new function
add_keyuse(), you skipped the initialization:
keyuse.ref_table_rows= 0;
was it intentional, and if so, why?
Timour
At file:///home/igor/maria/maria-5.3-mwl128
Zardosht,
I think we found out the problem. In ha_partition.cc, in the function
ha_partition::handle_ordered_index_scan, this code was added:
case partition_index_last:
/*
MyISAM engine can fail if we call index_last() when indexes disabled
that happens if the table
Igor,
Please review the attached patch for LP BUG#641203 we discussed last week.
Since there was no email service, the commit mail didn't get through, so
the commit comment is:
"
Fixed LP BUG#641203: Query returns rows where no result is expected
(impossible WHERE)
The cause for the bug w
Sergey,
I noticed these while building my recent bug fixes, but I
wanted to fix them in a separate patch. Patch will follow
very soon.
Timour
Hi Timour,
When one compiles 5.3, it produces the following warnings which I believe fall
into your turf. Could you please fix them:
item_subselect.cc
Igor,
Why not take the opportunity to change the format of all comments to
Doxygen format. It doesn't make sense to have two formats for comments,
and I've seen you adding new comments in new code in Doxygen format.
Timour
On 10/06/10 14:08, Sergey Petrunya wrote:
Hello Igor,
Please find some
Danny,
this the log from a short discussion about how to provide the
documentation for Sphinx to our users. Can you think of some
easy way to automate at least the notification process that
the docs changed?
knielsen, shodan IMHO it wuold be best if Sphinx could notify us
automatically about c
Hi, one correction below:
Hi,
Today I got really annoyed while debugging a server crash with GDB.
I never managed to make the same GDB reattach to a new process after
a crash. This means that after each crash one has to restart GDB, and
reattach to the new process.
After writing this, I decid
Hi,
Today I got really annoyed while debugging a server crash with GDB.
I never managed to make the same GDB reattach to a new process after
a crash. This means that after each crash one has to restart GDB, and
reattach to the new process.
As a result all breakpoints are lost, and need to be set
Sergei,
Hi, Timour!
On Jun 02, Timour Katchaounov wrote:
Hi,
I was looking today at some optimizer code, and bumped again
into sql_select.cc:find_best(). We have been using the greedy
optimizer for years, and this function has been dead code for
a while, isn't it time to remove it?
The
Hi,
I was looking today at some optimizer code, and bumped again
into sql_select.cc:find_best(). We have been using the greedy
optimizer for years, and this function has been dead code for
a while, isn't it time to remove it?
The less code, the better.
Timour
__
Adam,
I might also add...
*What happens when/if Canonical/Ubuntu goes bunk?
Using all of the tools provided by one vendor can be a great thing but not
if the vendor's existence is "tenuous." If that happens, how easy would it
be to migrate data away from the vendor and would we even have that
on
is needed or not.
My source of information is this page:
http://tinyurl.com/c3e5mh
(original:)
http://www.microsoft.com/downloads/details.aspx?familyid=727BCFB0-B575-47AB-9FD8-4EE067BB3A37&displaylang=en
Timour
[moving the discussion to maria-develop...@]
Timour Katchaounov writes:
Ser
Hi Arjen,
Hi Igor
On 14/12/2009, at 12:39 PM, Igor Babaev wrote:
There should be a common sense after all.
Adding 7K files from boost doesn't comply with a common sense.
no matter what Arjen thinks about it.
If oqgraph cannot do without boost in the MariaDB development tree we'd
better drop oq
27 matches
Mail list logo
