Does anyone have a different opinion or will this topic be closed?
Mesut Öncel , 1 Mar 2021 Pzt, 13:27 tarihinde şunu
yazdı:
> Thank you for your detailed explanation. You are right, they have tried to
> shape the database suitable for this structure for a long time, but
> removing the
Thank you for your detailed explanation. You are right, they have tried to
shape the database suitable for this structure for a long time, but
removing the expression indexes will not cause a crisis. People and
products using the database created by Django will already have to create a
standard
I kind of agree that using `UPPER` instead of `ILIKE` for `__icontains` on
PostgreSQL isn’t optimal. But it is quite easy to create a functional
trigram GIN-index which use `UPPER` to allow these lookups to use an index.
This will be even easier in Django 3.2 where you can create functional
Hi James,
Thanks for your explanations. However, I wanted to explain the disadvantage
of using "UPPER like" instead of "ilike" in icontains, istartswith and
iendswith. The performance problem should not be ignored.
James Bennett , 1 Mar 2021 Pzt, 04:05 tarihinde şunu
yazdı:
> On Sun, Feb 28,
On Sun, Feb 28, 2021 at 2:39 AM Tom Forbes wrote:
>
> Thank you for the clarification! I think the biggest argument for this change
> is the fact that uppercasing Unicode can cause incorrect results to be
> returned.
>
> Given that we now have much better support for custom index types, perhaps
The ticket I posted in the first email does not belong to me. The ticket I
opened is https://code.djangoproject.com/ticket/32485.
Sky Lord , 28 Şub 2021 Paz, 14:59 tarihinde şunu
yazdı:
> Guys, am noob anyone gonna guide?
>
> On Sun, Feb 28, 2021, 11:39 AM Tom Forbes wrote:
>
>> Thank you for
Guys, am noob anyone gonna guide?
On Sun, Feb 28, 2021, 11:39 AM Tom Forbes wrote:
> Thank you for the clarification! I think the biggest argument for this
> change is the fact that uppercasing Unicode can cause incorrect results to
> be returned.
>
> Given that we now have much better support
A discussion was requested from here to make changes on this issue. Do you
think it would be appropriate if I open a pull request for this change?
Mesut Öncel , 28 Şub 2021 Paz, 14:06 tarihinde şunu
yazdı:
> You're welcome. Yes, database administrators can create an index as
> desired. However,
You're welcome. Yes, database administrators can create an index as
desired. However, creating multiple cin indexes in a single column with
different methods will cause performance issues. I don't think using
expressions when using like and ilike is a correct use for query
performance.
It doesn't
Thank you for the clarification! I think the biggest argument for this
change is the fact that uppercasing Unicode can cause incorrect results to
be returned.
Given that we now have much better support for custom index types, perhaps
we should change this? We need a custom expression index
Thank you for the clarification!
On Sun, 28 Feb 2021 at 09:23, Mesut Öncel wrote:
> Yes, 7 years ago I reviewed the ticket for the updated code, but there are
> problems there.https: //code.djangoproject.com/ticket/32485 The ticket I
> opened has the necessary details. If you want more details,
Yes, 7 years ago I reviewed the ticket for the updated code, but there are
problems there.https: //code.djangoproject.com/ticket/32485 The ticket I
opened has the necessary details. If you want more details, I can make the
necessary explanations.
Tom Forbes , 28 Şub 2021 Paz, 12:36 tarihinde şunu
Unless I’m missing something, the ticket you linked was last updated 7
years ago with two now-broken images. Which ticket did you open with the
examples?
Tom
On Sun, 28 Feb 2021 at 08:31, Mesut Öncel wrote:
> The reason I opened all the problems in a single ticket was to show the
>
The reason I opened all the problems in a single ticket was to show the
disadvantages of the "UPPER" function used in the "icontains" operator.I
think that instead of using "UPPER (column) like" used in the Django ORM
filter method, the "icontains" operator should use the "ilike" operator and
this
Hey,
I think it would be best if you opened a new ticket explaining your issue
and the performance problems you’ve found (especially around Turkish
characters). I’m not entirely clear what you wish to be changed: you wish
for an expression index to be created automatically?
Tom
On Sat, 27 Feb
Hi,
I opened the ticket https://code.djangoproject.com/ticket/3575. In this
ticket, I wanted to prove the effect of UPPER function used in icontains
operator on indexes and query result. UPPER function causes performance
problems regarding indexing in PostgreSQL. Another issue is that it does
16 matches
Mail list logo
