<div dir="ltr"><div>Perhaps, but it's not a -1 so much as a call for more experimentation and testing.  I wouldn't feel comfortable saying Pulp is MySQL "compatible" if (if!) it was an order of magnitude slower than Pulp on Postgres, and we never found out about that because we never tested it... I think that kind of "compatibility" would be a net negative to Pulp.  So I just want us to make sure these bases are covered if we're going to make that claim.<br></div><div><br></div><div>s/it's chart chart/it's a pretty nasty chart<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 9:27 AM Dennis Kliban <<a href="mailto:dkliban@redhat.com">dkliban@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>It looks like the chart was generated using MySQL 5.0.45 which was released at least 10 years ago[0]. I don't think we can rely on such old results. <br></div><div><br></div><div>[0] <a href="https://en.wikipedia.org/wiki/MySQL#Milestones" target="_blank">https://en.wikipedia.org/wiki/MySQL#Milestones</a><br></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 9:18 AM Daniel Alley <<a href="mailto:dalley@redhat.com" target="_blank">dalley@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>I just want to point out that using UUID PKs works perfectly fine on PostgreSQL but is considered a Bad Idea<span class="m_7202120153688639214m_4833483098398381165gmail-ILfuVd"><b>™</b></span> on MySQL for performance reasons.  <br></div><div><br></div><div><a href="http://kccoder.com/mysql/uuid-vs-int-insert-performance/" target="_blank">http://kccoder.com/mysql/uuid-vs-int-insert-performance/</a></div><div><br></div><div><div><img src="cid:ii_jpb8p8mb0" alt="image.png" width="566" height="340"></div><div><br></div><div>It's hard to notice at first, but the blue and red lines (representing integer PKs) are tracking near the bottom.<br></div><div><br></div><div>I did my testing with PostgreSQL, and I would completely agree that the tiny performance hit we noticed there would take a backseat to the functional benefits Brian is pointing out.  But if we really, truly want to be database agnostic, we should put more thought into this change (and others going forwards).</div><div><br></div><div>Another factor that makes this a more complicated decision is that the limitations on using bulk_create() with multi-table models are more of a "simplification" on the Django side than a fundamental limitation.  According to this comment [0] in the Django source code, and this issue [1] it's likely possible on PostgreSQL as-is, if we were willing to mess around inside the ORM a bit.  And it could be possible on MySQL also *if* we used UUID PKs.  And maybe the performance benefits of being able to use bulk_create() would override or reduce the performance downsides of using UUID with MySQL.  I don't know about that though... that's chart chart and without some experimentation this is all speculation.</div><div><br></div><div>TL;DR If we want to stay DB agnostic it needs to be worked into our decision making process and not be an afterthought<br></div><div><br></div><div>[0] <a href="https://github.com/django/django/blob/master/django/db/models/query.py#L438" target="_blank">https://github.com/django/django/blob/master/django/db/models/query.py#L438</a></div><div>[1] <a href="https://code.djangoproject.com/ticket/28821" target="_blank">https://code.djangoproject.com/ticket/28821</a><br></div><div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 20, 2018 at 10:00 AM Patrick Creech <<a href="mailto:pcreech@redhat.com" target="_blank">pcreech@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2018-11-19 at 17:08 -0500, Brian Bouterse wrote:<br>
> When we switched from UUID to integers for the PK<br>
> with databases other than PostgreSQL [0].<br>
> <br>
> With a goal of database agnosticism for Pulp3, if plugin writers plan to use bulk_create with any object inherited<br>
> from one of ours, they can't will get different behaviors on different databases and they won't have PKs that they may<br>
> require. bulk_create is a normal django thing, so plugin writers making a django plugin should be able to use it. This<br>
> concerned me already, but today it was also brought up by non-RH plugin writers also [1] in a PR.<br>
> <br>
> The tradeoffs bteween UUIDs versus PKs are pretty well summed up in our ticket where we discussed that change [2].<br>
> Note, we did not consider this bulk_create downside at that time, which I think is the most significant downside to<br>
> consider.<br>
> <br>
> Having bulk_create effectively not available for plugin writers (since we can't rely on its pks being returned) I<br>
> think is a non-starter for me. I love how short the UUIDs made our URLs so that's the tradeoff mainly in my mind.<br>
> Those balanced against each other, I think we should switch back.<br>
> <br>
> Another option is to become PostgreSQL only which (though I love psql) I think would be the wrong choice for Pulp from<br>
> what I've heard from its users.<br>
> <br>
> What do you think? What should we do?<br>
<br>
So, my mind immediately goes to this question, which might be usefull for others to help make decisions, so I'll ask:<br>
<br>
When you say: <br>
<br>
"we lost the ability to have the primary key set during bulk_create"<br>
<br>
Can you clarify what you mean by this?<br>
<br>
My mind immediately goes to this chain of events:<br>
<br>
        When you use bulk_create, the existing in-memory model objects representing the data to create do not get<br>
updated with the primary key values that are created in the database.  <br>
<br>
        Upon a subsequent query of the database, for the exact same set of objects just added, those objects _will_ have<br>
the primary key populated.<br>
<br>
In other words, <br>
<br>
        The database records themselves get the auto-increment IDs added, they just don't get reported back in that<br>
query to the ORM layer, therefore it takes a subsequent query to get those ids out.<br>
<br>
Does that about sum it up?<br>
<br>
<br>
> <br>
> [0]: <a href="https://docs.djangoproject.com/en/2.1/ref/models/querysets/#bulk-create" rel="noreferrer" target="_blank">https://docs.djangoproject.com/en/2.1/ref/models/querysets/#bulk-create</a><br>
> [1]: <a href="https://github.com/pulp/pulp/pull/3764#discussion_r234780702" rel="noreferrer" target="_blank">https://github.com/pulp/pulp/pull/3764#discussion_r234780702</a><br>
> [2]: <a href="https://pulp.plan.io/issues/3848" rel="noreferrer" target="_blank">https://pulp.plan.io/issues/3848</a><br>
> _______________________________________________<br>
> Pulp-dev mailing list<br>
> <a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
<br>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
</blockquote></div>