Hi Simon, Thanks for tracking that down. I see - an interesting problem that lacks an obvious solution. Nevertheless, there is a generic way to deal with this and it will optimize OK in Oracle (at least in the vast majority of cases).
select x, sum(sal) from (select :arg0 * deptno as x, sal from emp) group by x; There would be a need to generate suitably obscure column aliases. So - not "x"! Also, more than one alias per SQL statement might be needed too of course. I don't think this should be used for all cases of aggregation. IMHO it would be best to target it based on how the Django model is used. I wonder if it would be possible to catch cases where a bind variable would normally be included in both the SELECT list and the GROUP BY. Regards, Nigel On Monday, 5 April 2021 at 15:45:31 UTC+1 charettes wrote: > Hello Nigel, > > Through git blame for unify_by_values I figured it was introduced[0] to > deal with an issue during aggregation[1]. > > Mariusz might be able to provide more context here as I don't have much > knowledge around Oracle cursor cache but it seems you'll have to find > another way to address the aggregation issue[1] if you'd like to change > this behaviour. > > Cheers, > Simon > > [0] > https://github.com/django/django/commit/6dbe56ed7855f34585884a2381fb1cec22ddc824 > [1] https://code.djangoproject.com/ticket/27632 > > Le samedi 3 avril 2021 à 18:30:28 UTC-4, NPB a écrit : > >> Hi, >> >> Can you tell me why *execute* in .../backends/oracle/base.py sets >> *unify_by_values=True* when it calls *_fix_for_params*? It has an >> interesting effect on the Oracle cursor cache. >> >> For example, if I use a Django model called Logger like this: >> >> from . import models >> ... >> a = models.Logger(t1="1", t2="2", t3="3", i1=1, i2=2, i3=3) >> a.save() >> b = models.Logger(t3="3", t2="2", t1="1", i3=3, i2=2, i1=1) >> b.save() >> c = models.Logger(t1="1", t2="2", t3="3", i1=1,i2=1,i3=3) >> c.save() >> d = models.Logger(t1="1", t2="2", t3="3", i1=3,i2=1,i3=3) >> d.save() >> e = models.Logger(t1="1", t2="1", t3="1", i1=1,i2=1,i3=1) >> e.save() >> >> It results in the following SQL statements in the Oracle cursor cache: >> >> INSERT INTO "POLLS_LOGGER" ("T1", "T2", "T3", "I1", "I2", "I3") VALUES >> (:arg0, :arg1, :arg2, :arg3, :arg4, :arg3) RETURNING "POLLS_LOGGER"."ID" >> INTO :arg5 >> INSERT INTO "POLLS_LOGGER" ("T1", "T2", "T3", "I1", "I2", "I3") VALUES >> (:arg0, :arg0, :arg0, :arg1, :arg1, :arg1) RETURNING "POLLS_LOGGER"."ID" >> INTO :arg2 >> INSERT INTO "POLLS_LOGGER" ("T1", "T2", "T3", "I1", "I2", "I3") VALUES >> (:arg0, :arg1, :arg2, :arg3, :arg4, :arg5) RETURNING "POLLS_LOGGER"."ID" >> INTO :arg6 >> INSERT INTO "POLLS_LOGGER" ("T1", "T2", "T3", "I1", "I2", "I3") VALUES >> (:arg0, :arg1, :arg2, :arg3, :arg3, :arg4) RETURNING "POLLS_LOGGER"."ID" >> INTO :arg5 >> >> Bind variable names are re-used and shuffled around if any share the same >> value. This results in multiple SQL IDs. >> >> If, instead, execute used *unify_by_values=False*, then the Oracle >> buffer cache would have a single version of the statement irrespective of >> bind values: >> >> INSERT INTO "POLLS_LOGGER" ("T1", "T2", "T3", "I1", "I2", "I3") VALUES >> (:arg0, :arg1, :arg2, :arg3, :arg4, :arg5) RETURNING "POLLS_LOGGER"."ID" >> INTO :arg6 >> >> On the face of it, the use of unify_by_values=False is more efficient (at >> least from the database's perspective) because there is only one hard >> parse. I guess it doesn't look like a big deal in this example, but I have >> seen cases where the cursor cache has (literally) tens of thousands of >> repeated cursor cache entries where one would have been used if bind names >> were kept consistent and independent of bind value. >> >> Do you think there is a valid case for this default behavior to be >> changed? >> >> Regards, >> Nigel >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3bf99bc3-d08b-4a16-9b44-7cf2fc749370n%40googlegroups.com.
