Kristian,
> Ok, then we should wait, as otherwise there will be annoying build failures
> resulting from this.
I am back from my trip now. I can offer my Fedora 13 32-bit and
Windows 7 Enterprise 32-bit up for build purposes. Like mentioned
before, I've got Python buildbot installed on Fedora. I
Thanks for the comprehensive responses!
I meant index_condition_pushdown at all times. All testing scripts
manipulate index_condition_pushdown and not engine_condition_pushdown.
Philip Stoev
- Original Message -
From: "Sergey Petrunya"
To: "Philip Stoev"
Cc:
Sent: Thursday, Decemb
On Thu, Dec 09, 2010 at 11:34:05AM +0200, Philip Stoev wrote:
> I have a few questions with respect to the feature so that I can test it
> better (we may have discussed those previously but I can not seem to find
> the email):
>
> - apart from mrr_sort_keys ON and OFF and engine_condition_pushdo
Hi,
I spend about some time (took about a day) trying to improve the current
state of windows build and packaging. Partly, I it was to improve my own
experience working on Windows (spoiled by MySQL5.5 :) with out-of-source
build, partly because I think the fact that the packaging (even zip)
require
Kristian Nielsen wrote:
> "Philip Stoev" writes:
>
>> This code was added as a fix for MySQL bug #38005 and then removed as
>> a fix for bug #46639
>
> Yes.
>
> Turns out that the removal part of Bug#46639 was lost in MariaDB in this
> merge:
>
> revno: 2732 [merge]
> revision-id: i...
Thank you to everybody for the clarification. We will fix our engine
to not set 0 for stats.records unless we are absolutely sure it is
empty.
-Zardosht
On Thu, Dec 9, 2010 at 7:52 AM, Sergei Golubchik wrote:
> Hi, Zardosht!
>
> On Dec 08, Zardosht Kasheff wrote:
>>
>> We always thought that sta
Hi, Zardosht!
On Dec 08, Zardosht Kasheff wrote:
>
> We always thought that stats.records was meant to be an estimate, and
> that an estimate of 0 was ok even if the table was non-empty. We were
> reporting that stats.records was 0 even though the table was
> non-empty. Is this assumption wrong?
"Philip Stoev" writes:
> This code was added as a fix for MySQL bug #38005 and then removed as
> a fix for bug #46639
Yes.
Turns out that the removal part of Bug#46639 was lost in MariaDB in this
merge:
revno: 2732 [merge]
revision-id: i...@askmonty.org-20091112043128-yd6odg8zr5ribjal
Hi Timour,
In Helsinki, we've noted the following:
> MWL#90: Subqueries: Inside-out execution for non-semijoin materialized
> subqueries in WHERE (4K diff); Critical task
> = Get the code reviewed/pushed
> TODO:
> - Timour will tell the "obvious things to improve"; Timour 1 day
I'm going t
Hi Philip,
The new version of MWL#121-125, DS-MRR impovements, is ready for your testing.
I believe all previously reported crashes and wrong query result bugs are no
longer there (they've been either targeted and fixed, or were gone after code
re-working I've made when addressing review feedback
This code was added as a fix for MySQL bug #38005 and then removed as a fix
for bug #46639
The comment for the revision that removed the code is:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
Problem was that when bulk insert is used on an empty table/pa
11 matches
Mail list logo
