ok, fair enough...
and you auto purge it every now and then...
/Jonas
On Fri, Dec 5, 2014 at 12:01 PM, Kristian Nielsen
wrote:
> Jonas Oreland writes:
>
> > A slightly off topic question that struck me last night: won't all
> parallel
> > transactions conflict when updating the slave_gtid_pos
Jonas Oreland writes:
> A slightly off topic question that struck me last night: won't all parallel
> transactions conflict when updating the slave_gtid_pos table ?
They would, if the GTID was not carefully designed in anticipation of this
issue.
So the GTID position is updated in slave_gtid_po
Jonas Oreland writes:
> I light of recent "I did see any of your comments until by accident just
> now",
> I now mail you directly that I updated both MDEV-162 and MDEV-7257.
Thanks. I'll definitely look into it, I will try to do it as soon as
possible. But it might be afew days, as things look
> i don't understand what "only_commits" is, how can it prepare transaction
> "queue up" for group commit
> if only 1 is prepared in parallel ?
Right, so this is an important optimisation, let me try to explain that, and
then I'll answer the other points in a different (shorter) mail for clarity.
Hi Kristian,
I light of recent "I did see any of your comments until by accident just
now",
I now mail you directly that I updated both MDEV-162 and MDEV-7257.
I want (review) comments.
/Jonas
___
Mailing list: https://launchpad.net/~maria-developers
P
I still prefer "auto" as default,
if you want the fine grained control, I think an optimizer_switch approach
is better than adding X new config options, i.e
--parallel_mode=option1=true,option3=4
don't you think that there will be new options/variants ? i do
don't you think you will want to remove
6 matches
Mail list logo
