Could anyone please explain data representation, both on disk and in
memory? Especially about BLOB fields
What was the reasons to move hot data from OS file cache to MySQL
memory? Is it great improvement of efficiency(to avoid kernel calls) or
necessity for future transaction support?
--
This mess
On Mon, 17 May 2010 11:14:15 -0700
Igor Babaev wrote:
Daniel> The original sentence from the worklog reads:
Daniel> So threads compete for this lock even in the case when they
Daniel> have acquired shared locks for the file and pages they want
Daniel> read from are in the key cache b
Hi!
On Wed, 19 May 2010 15:05:55 +0200, Sergei Golubchik
wrote:
>
> Yes, it only describes how the data get to the redundancy service, but
> not what happens there. I intentionally kept the details of redundancy
> out, to be able to satisfy a wide range of different implementations.
>
> For exa
Hi, Alex!
On May 13, Alex Yurchenko wrote:
> On Thu, 13 May 2010 16:36:41 +0200, Sergei Golubchik
> wrote:
>
> > * there's no explicit global transaction ID here, but I presume
> > there can be a filter that adds it to events. That would work, as
> > long as replication decides on the commit
Igor Babaev writes:
> Here's my review.
Thanks a lot for your help! I checked through all your points (few detailed
comments below), all your proposed solutions seem reasonable to me.
In summary, we should as you suggest:
- Rework patches for bugs 39022, 48483, and 49324 as you described (1,7
On Tue, May 18, 2010 at 5:15 PM, Igor Babaev wrote:
> Henrik Ingo wrote:
>> On Mon, May 17, 2010 at 9:14 PM, Igor Babaev wrote:
>>> 1. the author of the original patch
>>> 2. our community members (not only PeterZ!)
>>> 3. our developers
>>>
>>> what term they prefer 'Segmented Key Cache' or 'Par
6 matches
Mail list logo
