|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Доброго вечера,подскажите пожалуйста как сделать запрос типо такого Код: plsql 1.
Нужно чтобы в результирующем наборе были только те записи,чей channel_type удовлетворяет строго всем типам из входящих аргументов,а не одному из как было бы в случае с таким запросом Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.06.2021, 19:50 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
asv79 Доброго вечера,подскажите пожалуйста как сделать запрос типо такого Код: plsql 1.
Нужно чтобы в результирующем наборе были только те записи,чей channel_type удовлетворяет строго всем типам из входящих аргументов,а не одному из как было бы в случае с таким запросом Код: plsql 1.
из вашего не очень понятного описания я бы предположил такой вариант Код: sql 1. 2. 3. 4. 5.
-- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 00:06 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, такой вариант не подойдет,так как на вход в фильтр подается список значений тоесть в результирующем наборе должны быть только те записи,которые имеют все перечисленные в списке типы и заранее никто не знает количество элементов в этом списке ,только тип - строка. Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 09:48 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
asv79 на вход в фильтр подается список значений Это строка типа Код: sql 1.
? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 09:51 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
court asv79 на вход в фильтр подается список значений Это строка типа Код: sql 1.
? нет,это набор строковых значений- передается из java в формате List<String> тоесть будет Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 09:57 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Сейчас я изобразил вот такой вариант Код: plsql 1. 2. 3.
где на вход будет подаваться 'SMS,PUSH,EMAIL,....etc' в виде строки но мне это не очень подходит изза постфильтра - записей достаточно много и тащить их все из бд,затем накладывать having не очень хорошая идея ну и конечно не хочется преобразоывать список в строку типа 'SMS,PUSH,EMAIL,....etc' - проблем с этим нет,но это тоже не очень привествуется ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 10:02 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
asv79 Maxim Boguk, такой вариант не подойдет,так как на вход в фильтр подается список значений тоесть в результирующем наборе должны быть только те записи,которые имеют все перечисленные в списке типы и заранее никто не знает количество элементов в этом списке ,только тип - строка. Код: plsql 1.
Какие то проблемы сгенерировать нужное количество EXISTS в запросе? Основной вопрос - вам вообще на производительность запроса наплевать? Если на скорость работы наплевать то вариантов много можно придумать конечно. Если нет то вариант с N exits будет скорее всего самым быстрым. Ну и вопрос вам вообще что хочется - минимальный обьем програмирования или максимальная производительность в целом? -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 10:09 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Вариант с exists выглядит очень даже. Просто в джава-коде надо пришедший список с channel_type не передавать в запрос как есть, а для каждого элемента делать and exists в запросе. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 10:10 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk asv79 Maxim Boguk, такой вариант не подойдет,так как на вход в фильтр подается список значений тоесть в результирующем наборе должны быть только те записи,которые имеют все перечисленные в списке типы и заранее никто не знает количество элементов в этом списке ,только тип - строка. Код: plsql 1.
Какие то проблемы сгенерировать нужное количество EXISTS в запросе? Основной вопрос - вам вообще на производительность запроса наплевать? Если на скорость работы наплевать то вариантов много можно придумать конечно. Если нет то вариант с N exits будет скорее всего самым быстрым. Ну и вопрос вам вообще что хочется - минимальный обьем програмирования или максимальная производительность в целом? -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru производительность на первом месте ,подскажите пожалуйста как это будет выглядеть с генерацией EXISTS при условии что будет подаваться на вход List<String> либо вы предлагаете сделать это в джава коде?в джава коде проблем вроде быть не должно с этим спасибо за идею ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 10:21 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Предполагаю, что channel_type буквально десяток в прыжке разных. Если есть уникальный индекс person_channel (person_id, channel_type) то можно сделать Код: sql 1. 2. 3.
offset по числу значений в списке -1 ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 10:29 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Melkij Предполагаю, что channel_type буквально десяток в прыжке разных. Если есть уникальный индекс person_channel (person_id, channel_type) то можно сделать Код: sql 1. 2. 3.
offset по числу значений в списке -1 супер работает все отлично а можно обьяснить принцип по которому данный запрос отрабатывает - я смотрю на него и не очень врубаюсь-тоесть сначала он находит те записи в которых есть хотя бы одно значение из списка ,потом смотрит число вхождений по офсету и выдает совпадение наверх? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 11:12 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Melkij Предполагаю, что channel_type буквально десяток в прыжке разных. Если есть уникальный индекс person_channel (person_id, channel_type) то можно сделать Код: sql 1. 2. 3.
offset по числу значений в списке -1 а что по производительности? если в таблице будет миллион персон это будет 1 млн подзапросов? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 11:25 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Melkij Предполагаю, что channel_type буквально десяток в прыжке разных. Если есть уникальный индекс person_channel (person_id, channel_type) то можно сделать Код: sql 1. 2. 3.
offset по числу значений в списке -1 по аналитике не очень этот запрос даже на 800 персонах и всего 10 каналах 2 мс время выполнения правда planning time 0.277 Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 11:40 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
asv79, В ветке по бд все равно что там у вас в java. Вам надо либо сгенерить строку в in. Либо передать таблицу list в хранимку Либо сгенерить временную таблу в сессии бд и заджойнить ее с основной. Смотрите по нагрузочному тесту. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 12:47 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
asv79 а можно обьяснить принцип по которому данный запрос отрабатывает - я смотрю на него и не очень врубаюсь-тоесть сначала он находит те записи в которых есть хотя бы одно значение из списка ,потом смотрит число вхождений по офсету и выдает совпадение наверх? при наличии уникального индекса при условии in (N элементов) после offset N-1 может остаться строка только в том случае, если каждый из N элементов присутствует в выборке. Если хоть даже одно нет - то offset всё проглотит, 0 строк в подзапросе, получим exists() = false asv79 по аналитике не очень этот запрос даже на 800 персонах и всего 10 каналах 2 мс время выполнения Добавьте данных. Ну миллионов 10 строк хотя бы. На таких "объёмах" не имеет смысла ничего смотреть. Если же вам важны именно доли мс и 2мс уже медленно - то клиент-серверные субд вам вовсе не подходят. Латентность сети уже больше времени выполнения самих запросов получается. asv79 если в таблице будет миллион персон это будет 1 млн подзапросов? А зачем вам может понадобиться считать быстро весь миллион персон? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 14:07 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Melkij, +1 абстрактное время ни о чем не говорит. Да еще без реального набора данных по ТЗ. Самой проблемы пока не видно. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 14:19 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
PetroNotC Sharp, на надо ничего там никуда джоинить и тд Код: plsql 1. 2. 3.
динамически буду строить такой запрос в зависимости от количества элементов в ходящем списке и получаю вот такие показатели и что не маловажно в других запросах идет seq сканироание ,в этом же примере оно идесное собственно время меня удовлетворяет и я выберу этот вариант Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 14:27 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
asv79, >на надо ничего там никуда джоинить и тд = странный вы. Вам дали 4 варианта решения. Джойнить был 4ый. Вы ВЗЯЛИ ПЕРВЫЙ и сказали "не надо ничего там... ))))) LOL ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 14:33 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
asv79, >собственно время меня удовлетворяет и я выберу этот вариант = выше вам написали, что записей надо поболее. Но вам виднее. Проблем нет. Удачи! ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 14:37 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Melkij asv79 если в таблице будет миллион персон это будет 1 млн подзапросов? А зачем вам может понадобиться считать быстро весь миллион персон? не понял вопроса? есть миллион записей в таблице и вот мне подсказали ,что запрос ,который вы посоветовали будет делать столько же подзапросов,сколько в таблице записей речь вот про этот ваш запрос Код: java 1. 2.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 14:47 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
PetroNotC Sharp asv79, >собственно время меня удовлетворяет и я выберу этот вариант = выше вам написали, что записей надо поболее. Но вам виднее. Проблем нет. Удачи! Так я из того что вы написали вообще ничего не понял вот это например ->надо либо сгенерить строку в in Я понял что вы хотите чтобы я из списка сделал строку типо 'SMS,EMAIL....etc' это не проблема ,а где запрос сам куда это подставить? ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 14:54 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
asv79, Дак зачем если ничего не понял отвечать словом НЕТ? )))) Первый пункт это динамический sql Склеиваешь любой запрос. Или в in условие Или Куски подзапросов Код: sql 1. 2. 3.
И так далее. Можно и вьюху генерить на событие вставки записи. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 16:19 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
asv79, Пятый вариант триггер поставить и перечень SMS,EMAIL....etc' будет всегда автоматом в табле person Смотря что по бизнесу надо. OLAP/OLTP ... |
|||
:
Нравится:
Не нравится:
|
|||
17.06.2021, 16:21 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Так еще можно попробовать. Код: sql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 00:50 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk ... вариант с N exits будет скорее всего самым быстрым. это сомнительное утверждение для произвольного N До какого-то порога (допустим, N ~ 7-8) так и будет. Потом я бы ожидал перехода первенства к какому-то другому варианту. Но не факт, что оказавшийся следующим победителем, сохранит лидерство для "слишком больших" N и person_channel Код: sql 1. 2. 3. 4. 5.
здесь exists может либо использоваться в качестве фильтра, либо преобразуется в join В первом случае быстрее начнут "отдаваться строки", во втором, по вероятности, запрос в целом отработает быстрее, при наличии подходящих индексов. Смотрите, функционально этот запрос эквивалентен такому: (а при трансформации в джойн как-то так и будет, с точностью до перестановки порядка таблиц) Код: sql 1. 2. 3. 4. 5. 6.
тогда при добавлении третьего элемента поиска получается вот что: Код: sql 1. 2. 3. 4. 5. 6. 7.
Даже при наличии индексов, деградация производительности такого соединения по мере роста списка поиска, растёт достаточно быстро, чтобы проиграть, в конце концов, какому-то из альтернативных вариантов. Скорее всего, построенному на группировке тем или иным способом.... имхо... PS (типа, в коллекцию) среди вариантов записи реляционного деления встречается и вариант, который в данном случае мог бы быть выписан в таком роде: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
визуально он не похож на многообещающий в плане производительности. Хотя, на средних размерах данных и средней длине списка, может оказаться не сильно и хуже прочих. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 02:38 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
booby, Производительность в варианте с multiple exists перво на перво будет зависеть от селективности САМОГО селективного фильтра в наборе. Т.е. если условно у вас в условии на channel_type 'SMS' ,'PUSH', 'доставка голубями' и с 'SMS' ,'PUSH' по 10 миллионов строк а с 'доставка голубями' всего 10 строк то вариант с exists выйграет у любого мыслимого альтернативного варианта просто потому что он начнет с semijoin от exists (select from person_channel pc where p.id = pc.person_id and pc.channel_type= 'доставка голубями' ) и далее быстро проверит найденные 10 строк по остальным 2м exits. Все остальные варианты будут так или иначе скатываться с полным переборам таблицы person а зачастую и таблицы person_channel с соответствующей печальной производителностью. Если же у вас там 10 низкоселективных channel_type в условии - там надо думать как лучше и сравнивать на конкретных реальных или синтетических данных. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 10:31 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, Не думаю. То, что вы описываете, видится как комбинация джойна с фильтром, при которой какие-то exists уедут в семиджойн, а какие-то останутся в фильтрах. Допустим, что целевой построитель плана выполнения запроса достаточно умен, чтобы именно так и работать на релевантной статистике. Тогда та часть, которая останется в фильтрах отработает за разумное время только при наличии структур типа bitmap-индексов. (И, если они есть, то есть смысл вообще все оставить в фильтре) Иначе кролик сдохнет под тяжестью множественных лукапов. Принципиальный момент в такого рода задаче - по постановке всяко требуется полный просмотр person_channel, то есть фильтрация не снижает совсем, или не снижает сильно объём просматриваемых данных, даже при пробеге по bitmap-индексу. В этих обстоятельствах безфильтровый полный пробег по person_channel с группировкой и агрегацией вполне смотрится. И тем лучше, чем больше сама person_channel и список обязательных требований. Мне кажется вполне разумным ожидать, что рано или поздно он опередит вариант с exists. А при отсутствии bitmap-индексов - опередит несомненно, и на достаточно малых значениях длинах списка требований (пусть будет - ~7-8 ). Другой вопрос, что в варианте с группировкой кажется предпочтительным вместо ( Count(*) from таблица_требований ) иметь групповую функцию, дающую слепок группы требований, с которым непосредственно можно было бы сравнивать слепок списка каналов конкретного person_id. Для нумерованных списков длиной <= 64 можно было использовать bit_and, благо, он есть в postgress. Преимущество Count в том, что он сработает стандартно на любых объёмах, без изобретения дополнительных конструкций для поддержки списков требований большего размера. PS Думаю, что в случае использования технологий того рода, что в oracle называют "exadata" - с фильтрацией на диске, блочными индексами и прочими чудесами, даже bitmap-индексам не стоит начинать соревноваться с простым и незатейливым полным просмотром. имхо. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 11:33 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
booby, в паралельной теме мне предложили создать функциию ,которая будет создавать в памяти сессии временную таблицу с типами каналов Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Надо логику запроса поправить ,учитывая наличие временной таблицы,если конечно такой вариант вообще имеет место быть ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 11:42 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
с временной таблицей вы можете использовать любую из работоспособных ранее показанных логик в обоих ветка. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 11:45 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
booby с временной таблицей вы можете использовать любую из работоспособных ранее показанных логик в обоих ветка. а какой запрос в таком случае будет работать с временной таблицей- я честно не достаточно силен в такого рода запросах если не сложно покажите рабочий пример . ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 11:51 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
booby, "Принципиальный момент в такого рода задаче - по постановке всяко требуется полный просмотр person_channel," - с чего вы это взяли? Задача решения с exists именно избежать полного просмотра. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 12:26 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
booby, Для закрытия вопроса - вот полный test case про то как оно в реальности работает Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39.
А теперь тест: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26.
И никаких полных переборов person_channel как и ожидалось. "Допустим, что целевой построитель плана выполнения запроса достаточно умен, чтобы именно так и работать на релевантной статистике." - таки это базовая его функциональность - решать как такие вещи лучше делать. Учите матчасть и проверяйте свои теории на тестовых данных перед тем как советовать. PS: и даже в случае отсутствия селективного фильтра в наборе - продолжает работать неплохо и без seq scan по person_channel Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 12:56 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, Не подскажите а как будет выглядеть вариант запроса ,если я запишу типы каналов в временную таблицу ?заранее спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 13:08 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
asv79, Я бы не стал... временные таблицы в PG очень дорогое удовольствие и на вашей задаче они выйгрыша не дадут вообще ни в каком варианте (тем более если запрос предполагается вызывать часто). Советы про временные таблицы обычно идут от старых оракловодов где это могло помогать временами. Сам факт что появляется слово distinct - уже убивает любую надежду на разумную производительность. Тогда уж вместо временной таблицы конструктор values или unnest использовать (но выйгрыша это не даст). PS: в 99% случаев подобных задач если в вашем решении появилось слово distinct - вы что то сильно не то делаете. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 13:13 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, Спасибо .Применил ваш вариант первоначальный ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 13:24 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, Признаю, это не было умной идеей - свой пост мне оформлять в виде обращения к вам. Хотя я мог бы догадаться об этом по стилю вашей подписи. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 13:35 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
PetroNotC Sharp asv79, Пятый вариант триггер поставить и перечень SMS,EMAIL....etc' будет всегда автоматом в табле person Смотря что по бизнесу надо. OLAP/OLTP Хороший вариант. Но я-бы обсудил различные сценарии обратных (компенсирующих) DML когда мы например удаляем "SMS" из дочерней таблицы. И возможную легкую денормализацию родительской таблички. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 16:01 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
mayton, Конечно. Делал такое и была функция генерируйВьюху() А она вызывалась по триггеру на события как вставки так и удаления. То есть мы меняли схему бд. Но можно менять и нормализацию. Мы генерим идеи, а выбирает архитектор по многим факторам. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 19:14 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, +1 про distinct Не люблю его) ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 19:20 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
PetroNotC Sharp mayton, Конечно. Делал такое и была функция генерируйВьюху() А она вызывалась по триггеру на события как вставки так и удаления. То есть мы меняли схему бд. Но можно менять и нормализацию. Мы генерим идеи, а выбирает архитектор по многим факторам. Я вот щас еще раз сравнил реализацию materialized views в Оракле и в PG. В последнем - тухляк. Не поддерживаются fast-режимы. Это когда мы обновляем не весь mview а отслеживаем только изменённые data-rows по журналам. Всему импортозамещению я сочувствую. PG - конешно опенсорсный. Но блин... это-же сколько тонн человеко-часов надо потратить чтобы взять PG и впилить в него фичу (реально классную фичу) из Оракла. Мне-бы до конца жизни хватило сидеть и разбираться в исходниках постгреса. Увлекательное занятие было-бы на пенсии. Мдя. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 19:29 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Maxim Boguk, +1 про distinct Не люблю его) В тех специальных условиях, которые для себя сформулировал Максим, путём определения уникального индекса, никакого distinct технически не требуется. В данном конкретном случае существо дела совершенно в другом. 2mayton содержательный oracle-проект не только на db2, но даже на tibero db весьма непросто перенести. А перенести в postgress, для проекта сложностью в три - пять сотен человеко-лет, это примерно как человечеству переселиться, если не в соседнюю галактику, то, как минимум, на спутники Сатурна или Юпитера. При том, что круг идей и совокупность алгоритмов у любых разумно построенных субд совпадает на 95-98% Оставшиеся пара-тройка процентов образуют непреодолимую пропасть. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 21:02 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Господа. Правильно я понял что сабж относится к области: - вхождение множества А в множество Б. Или термин выше относится к варианту с временной таблицей? Например такой вариант составил Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 21:49 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Господа. Правильно я понял что сабж относится к области: - вхождение множества А в множество Б. ммм. не то, чтобы совсем не так, но, в целом - нет. Пусть Б- обязательное множество экзаменов, при сдаче которых студент из А-множетсва результатов сдачи экзаменов, переводится на следующий курс. (Здесь предполагается, что "двойки" в A не пишутся - если двойка, у студента просто нет записи в результатах экзаменов А) варианты задачи: 1) Требуется отобрать для перевода на следующий курс всех таких студентов, которые сдали не менее, чем множество обязательных экзаменов (требований). Если кроме обязательных сдали какие-то еще - то такие годятся, их тоже, несомненно переведут на следующий курс. Это обычное реляционное деление А на Б, с допустимым "остатком" 2) Отыскиваются только те, кто сдал набор экзаменов, точно равный указанному с множестве Б - не меньше, но и не больше. Это называют точным реляционным делением. Например, это претенденты на обычную стипендию. В них нехорошо помещать тех, кто сдал экзаменов больше обязательного списка. Таких надо в претенденты на повышенную стипендию определять. То есть это задача на отбор персон, соответствующих квалификационным требованиям. Если сказано в наборе обязательных требований к квалификации кандидата автор Java 11, Kotlin, Spring Boot, WebFlux, R2DBC и прочее; • legacy: Java 8, Groovy, Spring, Hibernate, ActiveMQ; • Git, Gitlab, Gitlab-CI; • Docker и Kubernetes; • JIRA, Confluence, Agile Scrum; • Quality gate: code coverage + vulnerabilities + maintainability. И хотя бы одного слова в резюме не встречается (например - "прочее"), то кандидат в любом случае на собеседование не вызывается. А если есть лишние слова - Fortran, Ada, C++, Julia, Oracle, Postgress, MySql, то человек вызывается на собеседование, если "остаток от деления" допускается, и не вызывается, если выполняется точное деление, "без остатка". ... |
|||
:
Нравится:
Не нравится:
|
|||
20.06.2021, 22:19 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
booby, Уникальный индекс в моём решении не требуется и никак на его эффект и скорость работы не влияет. PS: в контексте задачи обычно если мы о реляционном делении говорим обычно студент не может иметь два одинаковых сданных экзамена поэтому uniq обычно предполагается. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
Код: sql 1. 2. 3. 4. 5.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
Альтернативное решение которое действительно может быть быстрее если много низкоселективных условий будет иметь вид: SELECT * from person p where p.id IN (SELECT person_id FROM person_channel WHERE channel_type IN ('SMS', 'PUSH', 'POSTAL DOVE') GROUP BY person_id HAVING count(distinct channel_type)>=3); которое будет иметь константное более менее время работы вне зависимости от селективности набора channel_type Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Что проигрывает в 30 раз версии с exists НА СЕЛЕКТИВНОМ ФИЛЬТРЕ. Если же фильтр не селективен то получаем сравнимое время работы: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49.
В итоге еще раз подтверждается правило что надо тестировать тестировать и еще раз тестировать разные варианты как минимум на синтетике а в идеале на копии реальных данных и главное реальных запросов и фильтров (понимая распределения этих фильтов в production). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2021, 00:05 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
mayton PetroNotC Sharp mayton, Конечно. Делал такое и была функция генерируйВьюху() А она вызывалась по триггеру на события как вставки так и удаления. То есть мы меняли схему бд. Но можно менять и нормализацию. Мы генерим идеи, а выбирает архитектор по многим факторам. Я вот щас еще раз сравнил реализацию materialized views в Оракле и в PG. В последнем - тухляк. Не поддерживаются fast-режимы. Это когда мы обновляем не весь mview а отслеживаем только изменённые data-rows по журналам. Всему импортозамещению я сочувствую. PG - конешно опенсорсный. Но блин... это-же сколько тонн человеко-часов надо потратить чтобы взять PG и впилить в него фичу (реально классную фичу) из Оракла. Мне-бы до конца жизни хватило сидеть и разбираться в исходниках постгреса. Увлекательное занятие было-бы на пенсии. Мдя. Практика показала что если мы переносим сколь угодно большой ВЕБ проект (а я переносил как минимум один из топовых сайтов рунета с mysql на postgres в одни руки) - это не так уж сложно и вполне поддается решению за разумное время. Совсем другое дело когда надо перенести какой то биллинг или АБС с миллионами строк хранимок и (mat)views - там сложность переноса в том что там нарушена изоляция данных от кода и фактически мы не базу с данными и формализованным языком SQL переносим а переносим весь проект с языка А (хранимки ORACLE) на язык Б (хранимки postgresql) - и тут обьем работ конечно очень большой (хотя учитывая цену лицензии на оракел часто оправданный... не всегда конечно). Это как с С++ на Java переписать... вроде и похоже но автоматических трансляторов рабочих не существует. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2021, 00:12 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Интересная эта штука.... partial indexes. Вот попробовал. Но нужны реальные вероятности и взаимовязи предикатов SMS/Push/Email. На синтетике - не те ощущения. Вобщем пускай Стасик проверяет если хочет. И триггер надо добавить. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2021, 00:20 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk booby, Уникальный индекс в моём решении не требуется и никак на его эффект и скорость работы не влияет. ... вот что вы говорили: Maxim BogukСам факт что появляется слово distinct - уже убивает любую надежду на разумную производительность. Так вот, неизбежно distinct появляется только в варианте запроса с группировкой с последующим фильтром вида Код: sql 1.
когда пара (A.person_id, A.subject) неуникальна. И, если такая пара ограничена уникальностью, то это единственное обязательное вхождение distinct автоматически исчезает. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2021, 00:32 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
хм. на миллионе записей: Код: sql 1. 2. 3. 4. 5.
а на двух миллионах: Код: sql 1. 2. 3. 4. 5.
Как оперативка у бобика сдохла для построения битмап-карты, так сразу и Group By заиграл, негромкой дудочкой. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2021, 01:00 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
booby, Не, ну у нас то задача определена и вариант только один. Множество детей у мастера А должно обязательно содержать множество Б называемых автором фильтры. Поэтому и спросил как это одной фразой назвать. Так как оператор in проверяет вхождение одного элемента. А оператор EXCEPT то что надо но вроде только от постгри. Решение выше вообще вроде работает. Возможно это называется как вы написали Это обычное реляционное деление А на Б, с допустимым "остатком". ОК. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2021, 07:11 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
booby, Разница в том что в первом плане есть uniq индекс а во втором нет. Поэтому в первом плане не требуется стадия убирания дубликатов строк. Да и по скорости они не отличаются почти. 32MB work_mem достаточно на очень дофига bitmap scan строк. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2021, 10:07 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
добрался наконец до sqlfiddle - поиграться, и лучше понять, что происходит Долгое время никак не мог получить планов, похожих на те, "за которые я воевал", затем подумал - ну уж intersect-то должен... И, бинго! - intersect как раз и показал ... ну почти то, что требуется. В сравнении, стало более-менее понятно, как пытаться этого же примерно добиваться и для group by и для join-вариантов - надо всего лишь лишить систему "удобного", с её точки зрения, индекса для соединения и не давать возможности джойну зацепиться за высокоселективный параметр в фильтре. Group by показал себя довольно капризным - а) одно неловкое движение, и он норовит свалиться с группировки хешированием на группировку сортировкой, убивая все заложенные в него мечты безумным external 2-way merge sort б) при любом удобном случае пытается соскочить с bitmap index scan (такое впечатление, что он троечник, и в школе слишком часто уроки прогуливал). На фоне group by - inner join - не то, чтобы отличник, но уроков явно меньше прогулял. Тверд, напорист и непокобелим. Поэтому разговаривать с ним приходится практически матом - методом лишения его "любимых" индексов. Тогда он приходит в легкое замешательство, но напористо пытается сделать лучшее из того, что "нам не задавали". В целом молодец. В зависимости от распределения данных, общие итоги наблюдения таковы: join и intersect уверенно делят 1-2 место. intersect нигде не опускается ниже второго, иногда выходя на первое. Если join проиграл intersect-у, то с большой вероятностью проиграет и group by, который, в свою очередь, в целом держится молодцом на 3м месте, несмотря на склонность к сортировке, иногда выходя на второе и опережая join. Исходный вариант от Дейта с not exists( ... not exists...) и вариант с except не выдерживают конкуренции на больших объёмах. (разница между вариантом Дейта и пропагандируемым Селко Group By в логике на краях - у Дейта отсутствующим требованиям соответствуют все студенты, у Селко с group by - нет требований, значит и студентов, им соответствующих, быть не может). скрипты: а) под победу inner join, который здесь правда неплох, и умно использует знание статистики: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. 267. 268. 269. 270. 271. 272. 273. 274. 275. 276. 277. 278. 279. 280. 281. 282. 283. 284. 285. 286. 287. 288. 289. 290. 291. 292. 293. 294. 295. 296. 297. 298. 299. 300. 301. 302. 303.
Под не победу inner join. Он держится, то, что здесь если уж join, то желателен hash join - до него дошло. Но финту-другому его то ли недоучили, то ли сам прогулял. Зато group by перестаёт нервически реагировать на окружающую среду и, наконец, хотя бы приблизительно соображает, что же от него на самом деле требуется. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. 230. 231. 232. 233. 234. 235. 236. 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2021, 23:24 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
booby, О вот это уже серьезный аргументированный ответ! Изучу завтра уже на свежую голову. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2021, 23:35 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
На какой-же синтетике вы гоняете ваши бенчмарки. На табличках из 1-й колонки? А бедняга автор затащит это себе где 1 datarow равен блоку ... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2021, 23:51 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
mayton На какой-же синтетике вы гоняете ваши бенчмарки. На табличках из 1-й колонки? А бедняга автор затащит это себе где 1 datarow равен блоку Если не забыть vacuum analyze после загрузки данных сделать - там IOS (index only scan) идет на всех exists ветках и на размер собственно datarow у person_channel вообще пофигу (да и на размер datatow у person по большому счёту тоже). Вот как план выглядит на современной 13 версии базы (а не 9.6 которой 5 лет и которая EOL в сентябре) на данных от booby (вторая версия индекса) где сделан всетаки vacuum analyze после заливки данных. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44.
Тут за счет IOS и умного использования статистики - тут вариант с exists выигрывает у всех подряд. На второй версии индекса - результат несколько отличается по скорости но всеравно в пределах 300ms. В принципе добавить 2kb случайного payload в обе таблицы не сложно но это уже дело для завтра. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2021, 00:11 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
mayton На какой-же синтетике вы гоняете ваши бенчмарки. На табличках из 1-й колонки? А бедняга автор затащит это себе где 1 datarow равен блоку Так пузами только на синтетике и меряются. А еще обязательно на прогретых данных, и в одно рыло, без конкуренции за диски и процессор. А иначе всё колыхаться будет и оспариваться. В данном случае синтетический person приводит лишь к тому, что системе до лампады, как по нему бежать - по индексу или нет. Это имеет для данной задачи минорное значение. Основные шашки вокруг работы с person_channel рубятся. 2Maxim Boguk сдаётся, что маловато данных для конкретного окружения. Индекс коротковат, и, раз это ему плёвое дело - 6 раз отфулсканить uix_person_channel_p2 , значит, надо либо его просто грохнуть, и смотреть, что он будет делать дальше. Либо добавить строчек. То, что было выложено - выкладывалось в пределах готовности sqlfiddle как-то продолжать разговор, а не отвечать в стиле "ой, что-то случилось". Больше данных я просто не смог ему скормить. ------------------------ PS По ходу пьесы почитал то да сё вокруг вопроса "postgress и движение материи". Премного подивился. Кажется, за него кто-то всерьёз и плотно внезапно взялся, и так уж и давно. Я с разбегу не вынес суждения, кто точно и как это варит. В главных спонсорах Microsoft в лице CitusData и Fujitsu. Просто в спонсорах Amazon, IBM, Google и Yandex. Так, или иначе, но интенсивность бурления и развития вокруг предмета за последнюю пятилетку вполне произвела впечатление. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2021, 01:24 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
booby mayton На какой-же синтетике вы гоняете ваши бенчмарки. На табличках из 1-й колонки? А бедняга автор затащит это себе где 1 datarow равен блоку Так пузами только на синтетике и меряются. А еще обязательно на прогретых данных, и в одно рыло, без конкуренции за диски и процессор. 2Maxim Boguk сдаётся, что маловато данных для конкретного окружения. Индекс коротковат, и, раз это ему плёвое дело - 6 раз отфулсканить uix_person_channel_p2 , значит, надо либо его просто грохнуть, и смотреть, что он будет делать дальше. Либо добавить строчек. Таки на прогретых данных разницы не будет... там же не full index scan а index only scan который только нужные строчки в индексе проходит. Там full скана индекса ни в одной ветке не происходит. А тогда просто вопрос в том чтобы индекс в shared buffers лежал. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2021, 10:30 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, когда индекс в shared buffers - это и есть "прогретые данные". почему, кстати, вы не показывете, в сравнении, результаты от intersect? дело-то вот в чём: вы "топите" за очевидно нереляционное решение, с захардкоженными поисковыми параметрами. Это весьма условно и приблизительно может быть вообще отнесено к категории "sql" и "работа с базой данных". По сути, вы говорите, что частный случай - самый лучший, всегда исходите из частного случая. Вот если бы вы показали, как какой-то вариант рекурсивного, например, запроса наотмашь бьёт все остальные варианты работы с реляционной таблицей требований, это был бы совсем другой разговор. Вместо этого вы советуете таблиц вообще не использовать, потому что субд с таблицами работает плохо, т.е. - почти не умеет, а с захардкоженными значенями умеет работать очень хорошо... Это прямо зашибись какое-то, очевидно, что самый лучший профессиональный совет. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2021, 10:57 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, я применил запрос по вашему совету сам запрос выглядит так Код: plsql 1. 2. 3. 4. 5. 6. 7.
всего в таблице 2 млн респондентов индексы из вашего примера 1.уникальный на respondent_id channel_type 2.обычый индекс на channel_type аналитика по запросу Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
вопрос почему так долго ? может не хватает каких то индексов? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 12:08 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
O_79_O, Выглядит как более менее нормальная скорость на том количестве и распределении данных что у вас есть и при отсутствии (о чём я писал) селективного channel_type. Я бы рекомендовал включить track_io_timing в конфиге базы и сделать explain (analyze, costs, buffers, timing) запроса несколько раз может оно просто с дисков много читает первый раз и поэтому медленно. PS: а какие у вас настройки базы в части random_page_cost/seq_page_cost/shared_buffers? -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 12:22 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, насчет настроек сказать не могу - я не админ базы этой смотрите у меня вопрос такой вот этот запрос с лимитом Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
запрос выполняется за 100 мс теперь я тоже самое делаю но через хибернейтовский entityManager и получаю в лучшем случае 3 секунды от начала запроса через постман до получения джейсона по логам видно что хибер отправляет ровно тот же запрос с ровно теми же параметрами куда уходит 3 секунды - неужели на мапинг 12 простеньких объектов по времени как запрос без лимита из консоли- очень странное поведение ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 12:57 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
O_79_O, 1)"вот этот запрос с лимитом" - это другой запрос с другим планом который надо смотреть и кстати оптимизация запроса с limit совсем не тоже самое что оптимизация запроса на все строки. 2)через JDBC там вообще могут быть варианты как именно он запрос отправляет и без доступа к логам базы - на это ответить нельзя надо включать лог запросов в базе и смотреть ЧТО именно пришло от приложения с какими параметрами и сколько запрос выполнялся. PS: попробуйте в запрос добавить order by p.id OFFSET 0 LIMIT 12 и руками и для JDBC может поможет выбрать план подходящий под вас. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 13:46 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk O_79_O, 1)"вот этот запрос с лимитом" - это другой запрос с другим планом который надо смотреть и кстати оптимизация запроса с limit совсем не тоже самое что оптимизация запроса на все строки. 2)через JDBC там вообще могут быть варианты как именно он запрос отправляет и без доступа к логам базы - на это ответить нельзя надо включать лог запросов в базе и смотреть ЧТО именно пришло от приложения с какими параметрами и сколько запрос выполнялся. PS: попробуйте в запрос добавить order by p.id OFFSET 0 LIMIT 12 и руками и для JDBC может поможет выбрать план подходящий под вас. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru 1 по первому пункту - понял,но ведь работает все идеально - 90-100 мс меня вполне устраивают эти цифры 2.по второму вопросу сейчас попробую сделать логи ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 13:59 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
без добавления p.id запрос Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
аналитика Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
с сортировкой p.id Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 14:03 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
скорей всего проблема в том что Хибернейт не умеет полноценно работать с limit ибо сейчас я вижу что время ответа как раз похоже тому - что как если бы я сделал аналитику запроса этого без лимита - как раз жи 3 с лишним секунды мне видится что хибер выгребает из бд все - а потом отдает тебе кусок по лимиту например полнотектовый поиск из консоли дает 0.12 секунд а через приложение уже 500 мс - почти в 4000 раз дольше ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 14:20 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
O_79_O, попробуй как тут пишут https://stackoverflow.com/questions/1239723/how-do-you-do-a-limit-query-in-jpql-or-hql ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 14:31 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
mayton O_79_O, попробуй как тут пишут https://stackoverflow.com/questions/1239723/how-do-you-do-a-limit-query-in-jpql-or-hql так и делаю ,никаких результатов - тоже самое если просто руками прописываю лимит в sql стетмейнт ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 14:35 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Ты не разобрался как я вижу на какую фазу SQL тратится время. Я напомню. 1) Фаза execution . Это работа числто в пространстве процесса PG (сортировки группировки и джойны). Данные при этом в сокет JDBC еще не выдаются. 2) Фаза fetch . Здесь PG начинает выдавать строки row-by-row по JBDC линку. И здесь работает Hiber-mapping и вообще вся твоя бизнес-логика. Замеряй время (в милисекундаз) в 3х точках и вычисли дельту между ними и ты получишь эти два интервала. Как только мы узнаем где проблема (какой интервал длиннее) - так мы и будем фиксить. Без этой информации у нас нет стратегии. Неясно что мы ищем и где. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 14:45 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
mayton Ты не разобрался как я вижу на какую фазу SQL тратится время. Я напомню. 1) Фаза execution . Это работа числто в пространстве процесса PG (сортировки группировки и джойны). Данные при этом в сокет JDBC еще не выдаются. 2) Фаза fetch . Здесь PG начинает выдавать строки row-by-row по JBDC линку. И здесь работает Hiber-mapping и вообще вся твоя бизнес-логика. Замеряй время (в милисекундаз) в 3х точках и вычисли дельту между ними и ты получишь эти два интервала. Как только мы узнаем где проблема (какой интервал длиннее) - так мы и будем фиксить. Без этой информации у нас нет стратегии. Неясно что мы ищем и где. майтон можешь не засорять тему ? спасибо заранее ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 14:51 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
O_79_O mayton O_79_O, попробуй как тут пишут https://stackoverflow.com/questions/1239723/how-do-you-do-a-limit-query-in-jpql-or-hql так и делаю ,никаких результатов - тоже самое если просто руками прописываю лимит в sql стетмейнт Я вам уже написал - без доступов к логам базы (и включению log_min_duration_statement) для понимания что именно от приложения в базу приходит и с какими параметрами - на эти вопросы ответить нельзя. Просите логи базы с параметрами и временем выполения или сами смотрите. Или тестовую базу у себя поднимайте с тестовыми данными и гоняйте на ней с включеными логами. Без этой информации нет смысла в дальнейшей дискуссии. Я не помню проблем с jdbc и limit у postgresql в тех местах где он используется. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 15:18 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk Я вам уже написал - без доступов к логам базы (и включению log_min_duration_statement) для понимания что именно от приложения в базу приходит и с какими параметрами - на эти вопросы ответить нельзя. Просите логи базы с параметрами и временем выполения или сами смотрите. Или тестовую базу у себя поднимайте с тестовыми данными и гоняйте на ней с включеными логами. Без этой информации нет смысла в дальнейшей дискуссии. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru база у меня поднята локально,но я понятия не имею как там смотреть логи ( я на винде работаю) и как включать параметры ,а которых вы говорите ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 15:36 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, таки домучал логи вот что из приложения прилетает Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178. 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. 193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207. 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 16:58 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
а вот это образуется в логах если сделать запрос из консоли Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 17:05 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
да,там видно что идут лишние селекты - это инициализируются коллекции- но они там ничтожно мало же занимают= откуда почти 7 секунд взялось непонятно ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 17:07 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
O_79_O откуда почти 7 секунд взялось непонятно автор2021-07-12 16:55:35.238 MSK [7888] LOG: execute <unnamed>/C_42: select count(*) from respondent p where exists (select from respondent_channel rc where p.id=rc.respondent_id and rc.channel_type = 'EMAIL') and exists (select from respondent_channel rc where p.id=rc.respondent_id and rc.channel_type = 'SMS') and exists (select from respondent_channel rc where p.id=rc.respondent_id and rc.channel_type = 'PUSH') and p.space_id = 1 and p.deleted_at is null 2021-07-12 16:55:41.657 MSK [7888] LOG: duration: 6419.398 ms ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 17:18 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Melkij O_79_O откуда почти 7 секунд взялось непонятно автор2021-07-12 16:55:35.238 MSK [7888] LOG: execute <unnamed>/C_42: select count(*) from respondent p where exists (select from respondent_channel rc where p.id=rc.respondent_id and rc.channel_type = 'EMAIL') and exists (select from respondent_channel rc where p.id=rc.respondent_id and rc.channel_type = 'SMS') and exists (select from respondent_channel rc where p.id=rc.respondent_id and rc.channel_type = 'PUSH') and p.space_id = 1 and p.deleted_at is null 2021-07-12 16:55:41.657 MSK [7888] LOG: duration: 6419.398 ms этот же запрос в консоли Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29.
странно почему разница в два раза ну и даже 3 секунды это перебор,можно с этим что то сделать на ваш взгляд? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 17:30 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
сделал без аналайза ну и собственно результат на лицо этот запрос из консоли выдает результат за почти 7 секунд ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 17:52 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
СОбственно теперь вопрос к знатокам - есть ли какие то способы убыстрить count(*) ( судя по всему нет - я почитал доки постгреса) и если так ,то может можно как то достать общее количество из первого запроса который выглядит вот так Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 18:00 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
причем count так плохо работает только с этим запросом , напрмер с полнотектовым поиском он за 500 мс Код: plsql 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 18:39 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
таже самая участь стала и селектом на интерсетах Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
теже самые 6.5-7 секунд ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 19:09 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
я так понимаю единственный вменяемый по скорости способ получить количество элементов можно лишь распарсив план ,но там есть допуск около 1% ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 22:06 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
O_79_O я так понимаю единственный вменяемый по скорости способ получить количество элементов можно лишь распарсив план ,но там есть допуск около 1% там допуск и 100% может быть... это как база себе представляет... что может сильно с реальностью расходится. Например есть у вас миллион respondent и есть по 500.000 SMS и 500.000 PUSH база будет предполагать что распределение случайное и соотвественно тех у кого и sms и push есть 250.000 а в реальности их может быть и 0 (у половины только sms а у второй половины только push) и 500.000 (у 500.000 и SMS и PUSH у вторых 500.000 - ничего). В обоих случаях explain вам 250.000 ожидаемых строк вернёт. Так что у этого метода много ограничений и подводных камней. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 22:41 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk O_79_O я так понимаю единственный вменяемый по скорости способ получить количество элементов можно лишь распарсив план ,но там есть допуск около 1% там допуск и 100% может быть... это как база себе представляет... что может сильно с реальностью расходится. Например есть у вас миллион respondent и есть по 500.000 SMS и 500.000 PUSH база будет предполагать что распределение случайное и соотвественно тех у кого и sms и push есть 250.000 а в реальности их может быть и 0 (у половины только sms а у второй половины только push) и 500.000 (у 500.000 и SMS и PUSH у вторых 500.000 - ничего). В обоих случаях explain вам 250.000 ожидаемых строк вернёт. Так что у этого метода много ограничений и подводных камней. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru понял ,спасибо за совет) а что тогда пагинация на постгресе в своем классическом исполнении не возможна получается? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 22:57 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
попробовал и такой варинат Код: plsql 1. 2. 3. 4.
2.3 секунды но тоже никуда не годится конечно ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 23:00 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
O_79_O Maxim Boguk пропущено... там допуск и 100% может быть... это как база себе представляет... что может сильно с реальностью расходится. Например есть у вас миллион respondent и есть по 500.000 SMS и 500.000 PUSH база будет предполагать что распределение случайное и соотвественно тех у кого и sms и push есть 250.000 а в реальности их может быть и 0 (у половины только sms а у второй половины только push) и 500.000 (у 500.000 и SMS и PUSH у вторых 500.000 - ничего). В обоих случаях explain вам 250.000 ожидаемых строк вернёт. Так что у этого метода много ограничений и подводных камней. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru понял ,спасибо за совет) а что тогда пагинация на постгресе в своем классическом исполнении не возможна получается? А она ни на какой базе не возможна на хоть сколько то разумных обьемах... count(*) по 1.000.000 будет работать ВСЕГДА приблизително столько же сколько select * по этим же миллионам строк (и никакая база вам это не ускорит). Потому что 90% времени это найти нужные вам строки а подсчитать их или отдать как есть - в пределах погрешности. Более того - никто уже не делает пагинацию больше чем на 5-10 страниц потому что это просто никому не нужно в реальности. Ну вот будет у вас пагинация на 10000 страниц... вот кому и какая прикладная для этого польза? Особенно учитывая тот милый факт (про который алогеты "пагинация на постгресе в своем классическом исполнении" не помнят) что она никогда не будет корректно работать на базе в которой идёт запись в используемые в запросе таблицы. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 23:31 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
O_79_O таже самая участь стала и селектом на интерсетах Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
теже самые 6.5-7 секунд Что вполне ожидаемо потому что количество строк к пересчёту округлённо тоже самое или даже выше тут. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 23:32 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
O_79_O причем count так плохо работает только с этим запросом , напрмер с полнотектовым поиском он за 500 мс Код: plsql 1. 2. 3. 4. 5. 6. 7.
Так тут строк намного меньше обрабатывать в процессе надо. count(*) с итогом в 1000.000 вероятнее всего будет не менее чем в 1000 раз медленее чем count(*) с итогом в 1000 если запрос одной структуры. Это не count(*) плохо работает а запрос на выборку сложную 300.000 строк не быстрый выходит. Я бы еще включил track_io_timing в конфиге и делал бы explain (analyze,costs,buffers,timing) запросов может у вас 3/4 времени работа с диском занимает и тогда просто базе надо больше памяти будет выдать и все ускорится заметно. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
12.07.2021, 23:36 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk, включил в конфигах что вы сказали Код: plsql 1. 2. 3. 4. 5. 6. 7.
запрос аналитика Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 00:08 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
O_79_O, ну вот 1)у вас оно мало того что временные файлы пишет так ещё и большую часть времени запроса читает данные с диска. Хотите быстрее 1)ставим work_mem в 32MB 2)ставим shared_buffers в 2GB хотя бы (я надеюсь что у вас локально 8GB хотя бы есть.. если есть 16GB то 4GB shared buffers) 3)ставим random_page_cost=1.1 4)перезапускаем базу 5)делает этот же самый explain (analyze,costs,buffers,timing) не 1 раз а раза 3-4 пока время выполенения не перестанет меняться. Смотрим какое время получилось. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 00:48 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk O_79_O, ну вот 1)у вас оно мало того что временные файлы пишет так ещё и большую часть времени запроса читает данные с диска. Хотите быстрее 1)ставим work_mem в 32MB 2)ставим shared_buffers в 2GB хотя бы (я надеюсь что у вас локально 8GB хотя бы есть.. если есть 16GB то 4GB shared buffers) 3)ставим random_page_cost=1.1 4)перезапускаем базу 5)делает этот же самый explain (analyze,costs,buffers,timing) не 1 раз а раза 3-4 пока время выполенения не перестанет меняться. Смотрим какое время получилось. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru спасибо большее буду пробовать ,завтра отпишусь что вышло ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 01:08 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Maxim Boguk,большое спасибо за советы- вообщем стало быстрее где то раза в два раза.ПРактически влез в SLA Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 17:24 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
Максим еще один вопрос хотел спросить,для сортировки по фио я создал вот такой индекс Код: plsql 1.
и так же есть индекс Код: plsql 1. 2. 3. 4. 5. 6.
так вот если я делаю такой запрос Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
не будет ли битри индекс fio_respondent мешать полнотекстовому поиску для которого у меня gin index full_text_search_respondent_gin аналитика по этому запросу Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 17:49 |
|
Селект с фильтром,который выдаст только те записи котороые удовлетворяют условию
|
|||
---|---|---|---|
#18+
я так понимаю это опять сложная тема,так как то что я смог нарыть говорит о том ,что слон вроде и может использовать несколько индексов в одном query но только в булевом выражении,что означает ,что если я хочу полнотекст по gin а сортировку по b tree такое не получится но в любом случае когда считается count(*) используется именно gin это хорошо когда поиск с лимитом используется btree когда поиск без лимит планировщик опять использует gin исходя из этого я предполагаю что эти индексы друг другу не мешают,планировщик сам выберет нужный в зависимости от ситуации ... |
|||
:
Нравится:
Не нравится:
|
|||
13.07.2021, 19:41 |
|
|
start [/forum/topic.php?all=1&fid=53&tid=1993940]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
111ms |
get tp. blocked users: |
1ms |
others: | 277ms |
total: | 465ms |
0 / 0 |