|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
andrey_anonymous Аудитор пару часов спокойно подождет точных данных, если они ему реально нужны. Но, полагаю, даже аудитор для оценки положения дел примет цифру с точностью +-1%. С третьей стороны, если Вы заранее знаете типовые вопросы аудитора, то ничто не мешает считать цифирь по закрытию банковского дня и откладывать в сторону. +1 ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2021, 18:46 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
PuM256 verter SQL*Plus, да, проблема решается только включением параллельности, т.е. вот так: А ещё проблема может решаться (а может и не решаться) построением дополнительных индексов. Чтобы не гадать на кофейной гуще, лучше сразу бы приложили план с +ALLSTATS или репорт SQL Monitor. +1 еще distinct может портить план запроса, выключать, например, single partition. с индексами у Кайта есть красивый иерархический пример построения distinct. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2021, 19:10 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
SQL*Plus Пример не убедительный. Я не собираюсь кого-либо в чем-то убеждать, как говорится - "по вопросам веры идите в церковь". Реальная жизнь такова что иногда приходится делать то, что должно, а не то, что хочется. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2021, 19:57 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
А как аудитор узнает, что ему дали данные, на .5% отличающиеся от факта? Сам он их считать не будет на миллионах транзакций. Какие дадут, на те и обопрётся. Для него это просто цифры, причем не сильно отличающиеся. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2021, 21:35 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
verter к сожалению стало даже дольше. а так? select count(count(*)) cc from tbl group by CODE, NAME ps +PARALLEL(xx) ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2021, 14:50 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
Впервые вижу, что кто-то так активно продвигает функцию приближенного вычисления. Во-первых, в общем случае аналитик, решающий задачу поиска distinct-значения, бесконечно далек от финальной цели поиска ответа и не может оценить требуемую точность. Более того, человек, ставящий ему задачу тоже может не понимать этого, особенно если речь идет о финансовых и бухгалтерских расчетах. Во-вторых, сама приближенная функция дает не какую-то заранее известную ошибку, она тупо не гарантирует никакой заранее известной точности! Это не научный подход. На такую функцию можно положиться, когда ты для своих целей что-то делаешь и в любой момент можешь переделать решение на 100% точное. А не в случае, когда кто-то зачем-то попросил тебя посчитать число и уже никогда не вернется к тебе, думая, что получил единственно верный, абсолютно точный ответ, а по факту не доплатит налоги в размере 3% от месячной выручки Мегафона или, если перевести в рубли, примерно 3 года тюрьмы. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2021, 16:47 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
Кстати, заметил такую вещь. Если делать выборку с параллелизмом, т.е. Код: plsql 1. 2.
то ничего кроме хинта PARALLEL оптимизатору не нужно, параллельность включается. А вот если хочется включить параллельность на вставку в таблицу, т.е. Код: plsql 1. 2. 3.
то одного хинта не достаточно, нужно сначала перед вставкой выполнить: Код: plsql 1.
а потом после вставки выполнить соответственно: Код: plsql 1.
Это почему так? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2021, 16:58 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
verter Это почему так? Потому что SELECT не есть DML и ему не надо заморачиваться с трансакционностью, "stable set of rows", и.т.д. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2021, 17:59 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
lav314 приближенная функция дает не какую-то заранее известную ошибку, она тупо не гарантирует никакой заранее известной точности ! Это не научный подход. Не научный подход - это ляпнуть на весь лес авторитетное мнение, не изучив матчасть. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2021, 18:05 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
SY verter Это почему так? Потому что SELECT не есть DML и ему не надо заморачиваться с трансакционностью, "stable set of rows", и.т.д. SY. А более конкретно, от старта parallel DML и до commit/rollback не будут работать ни другие DML, ни даже простые селекты. Так что с ними надо быть очень осторожным. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2021, 11:12 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
verter Кстати, заметил такую вещь. Если делать выборку с параллелизмом, т.е. Код: plsql 1. 2.
то ничего кроме хинта PARALLEL оптимизатору не нужно, параллельность включается. А вот если хочется включить параллельность на вставку в таблицу, т.е. Код: plsql 1. 2. 3.
то одного хинта не достаточно, нужно сначала перед вставкой выполнить: Код: plsql 1.
а потом после вставки выполнить соответственно: Код: plsql 1.
Это почему так? Но, например, автономной базе данных конфигурации Data Warehouse параллельное выполнение DML включено по умолчанию. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2021, 20:23 |
|
Замена DISTINCT
|
|||
---|---|---|---|
#18+
verter, А вы пробовали DISTINCT заменить на group by ? Я не знаю почему, но иногда это работает намного быстрее. Код: plsql 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
07.10.2021, 07:52 |
|
|
start [/forum/topic.php?fid=52&gotonew=1&tid=1879844]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
177ms |
get topic data: |
12ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 309ms |
0 / 0 |