AH
хз, что хуже, получать лишний раз .all() или же 2 запроса делать)
first_name_query = MyModel.objects.filter(first_name=text)
if first_name_query.exists():
return first_name_query.all()
Size: a a a
2020 June 29
I
подскажите плс, в таком кейсе будет два запроса в базу или один?
Да ты можешь сразу алл вернуть
N
подскажите плс, в таком кейсе будет два запроса в базу или один?
first_name_query = MyModel.objects.filter(first_name=text)
if first_name_query.exists():
return first_name_query.all()
вообще это странно выглядит
N
зачем там 4 пробела?
N
AH
зачем там 4 пробела?
поплыло)
DB
подскажите плс, в таком кейсе будет два запроса в базу или один?
first_name_query = MyModel.objects.filter(first_name=text)
if first_name_query.exists():
return first_name_query.all()
один запрос на
all тоже ленивый
exists()all тоже ленивый
N
я бы сделал один запрос на all, и проверил внутри элементы
I
один запрос на
all тоже ленивый
exists()all тоже ленивый
Ну он если выполниться будет два )
AH
один запрос на
all тоже ленивый
exists()all тоже ленивый
в любом случае при кейсе, когда exists() вернёт tru - это 2 запроса будет, так что по всей видимости проще all сразу вернуть
DB
Ivan
Ну он если выполниться будет два )
Если выполнится будет два. Но exists() сильно быстрее чем доставание из базы и сериализация в модели, кмк
DB
В целом зависит от задачи, да
Если оно там дальше не фильтерится больше, а так и обрабатывается, то можно .all() возвращать
Если дальше идёт бранчевание и с пустым кверисетом код не работает, то я бы предпочёл exists()
Если оно там дальше не фильтерится больше, а так и обрабатывается, то можно .all() возвращать
Если дальше идёт бранчевание и с пустым кверисетом код не работает, то я бы предпочёл exists()
NC
Если выполнится будет два. Но exists() сильно быстрее чем доставание из базы и сериализация в модели, кмк
+++ не стоит боятся экзистс и каунт, они дешевые
А
Nikolay Cherniy
+++ не стоит боятся экзистс и каунт, они дешевые
каунт дешевая?
NC
каунт дешевая?
да
NC
ну если сравнивать с тем что ты тягаешь все данные, а потом считаешь, как сам думаешь?)
А
https://postgrespro.ru/docs/postgrespro/12/functions-aggregate
Примечание
Пользователи с опытом использования других СУБД SQL могут быть недовольны скоростью агрегатной функции count, когда она применяется ко всей таблице. Подобный запрос:
SELECT count(*) FROM sometable;
потребует затрат в количестве, пропорциональном размеру таблицы: Postgres Pro придётся полностью просканировать либо всю таблицу, либо один из индексов, включающий все её строки.
Примечание
Пользователи с опытом использования других СУБД SQL могут быть недовольны скоростью агрегатной функции count, когда она применяется ко всей таблице. Подобный запрос:
SELECT count(*) FROM sometable;
потребует затрат в количестве, пропорциональном размеру таблицы: Postgres Pro придётся полностью просканировать либо всю таблицу, либо один из индексов, включающий все её строки.
А
помимо этого есть статьи, как ускорить каунт вроде приблизительного подсчета через костыли базы
NC
https://postgrespro.ru/docs/postgrespro/12/functions-aggregate
Примечание
Пользователи с опытом использования других СУБД SQL могут быть недовольны скоростью агрегатной функции count, когда она применяется ко всей таблице. Подобный запрос:
SELECT count(*) FROM sometable;
потребует затрат в количестве, пропорциональном размеру таблицы: Postgres Pro придётся полностью просканировать либо всю таблицу, либо один из индексов, включающий все её строки.
Примечание
Пользователи с опытом использования других СУБД SQL могут быть недовольны скоростью агрегатной функции count, когда она применяется ко всей таблице. Подобный запрос:
SELECT count(*) FROM sometable;
потребует затрат в количестве, пропорциональном размеру таблицы: Postgres Pro придётся полностью просканировать либо всю таблицу, либо один из индексов, включающий все её строки.
И?
А
нельзя утверждать, что это дешевая операция в отличие от екзиста