результаты за исключением изменения запроса после многократных последовательных прогонов в красном смещении

Я запускаю запрос postgresql ниже в aws redshift. Каждый раз, когда я запускаю этот запрос, я получаю другой результат для количества записей, которые различаются на стороне daily_table.product_repeat_sub_query, с использованием оператора except. Ни таблица daily_table.product_repeat_sub_query, ни daily_table.daily_sku_t в это время не обновляются. таблица daily_table.product_repeat_sub_query и запрос product_repeat_sub_query имеют одинаковое количество записей. схема daily_table.daily_sku_t приведена ниже, соответствующие поля в daily_table.product_repeat_sub_query имеют одинаковые типы данных. Я также включил некоторые образцы записей из таблиц ниже. Кто-нибудь знает, как результаты запроса except могут быть разными при каждом запуске этого запроса, когда базовые таблицы не меняются?

daily_table.daily_sku_t schema:

customer_uuid string
boardname_12 string
producttype string
productsubtype string
storeid int
product_id string
dateclosed date
Size string

запрос:

with product_repeat_sub_query as
(
        select
            dateclosed, t.product_id, t.storeid, t.producttype, t.productsubtype, t.size, t.boardname_12,
            case
                when ticketid = first_value(ticketid) over (partition by t.product_id, customer_uuid
            ORDER BY
                dateclosed ASC rows between unbounded preceding and unbounded following) then 0
                else grossreceipts
            end as product_repeat_gross, datediff(day,
            lag(dateclosed, 1) over (partition by t.boardname_12, customer_uuid, t.product_id
        ORDER BY
            dateclosed ASC ),
            dateclosed) as product_cycle_days
        from
            daily_table.daily_sku_t t )
            
select count(*) from
(
select dateclosed, storeid, boardname_12, producttype, productsubtype, size, product_id, product_cycle_days from daily_table.product_repeat_sub_query
except
select dateclosed, storeid, boardname_12, producttype, productsubtype, size, product_id, product_cycle_days from product_repeat_sub_query
);

-- 36843 -- 36887 -- 36188

данные:

daily_table.product_repeat_sub_query

dateclosed  storeid boardname_12    producttype productsubtype  size    product_id  product_cycle_days
2021-04-23  427     22RED                       DRUMER          1T  000011aa-4f03-4f0b-a621-xxxxxxxxxxxx    2
2021-04-24  427     22RED                       DRUMER          1T  000011aa-4f03-4f0b-a621-xxxxxxxxxxxx    6
2021-04-26  427     22RED                       DRUMER          1T  000011aa-4f03-4f0b-a621-xxxxxxxxxxxx    8
2021-04-26  427     22RED                       DRUMER          1T  000011aa-4f03-4f0b-a621-xxxxxxxxxxxx    3
2021-05-01  427     22RED                       DRUMER          1T  000011aa-4f03-4f0b-a621-xxxxxxxxxxxx    13
2020-06-18  61      FLAV RX         WINGER      BEVERAGE        100MT   0000265d-6b81-4d79-90cf-xxxxxxxxxxxx    5
2020-06-29  

product_repeat_subquery

dateclosed  storeid boardname_12    producttype productsubtype  size    product_id  product_cycle_days
2021-04-23  427     22RED           DRUMER                      1T  000011aa-4f03-4f0b-a621-xxxxxxxxxxxx    2
2021-04-24  427     22RED           DRUMER                      1T  000011aa-4f03-4f0b-a621-xxxxxxxxxxxx    6
2021-04-26  427     22RED           DRUMER                      1T  000011aa-4f03-4f0b-a621-xxxxxxxxxxxx    8
2021-04-26  427     22RED           DRUMER                      1T  000011aa-4f03-4f0b-a621-xxxxxxxxxxxx    3
2021-05-01  427     22RED           DRUMER                      1T  000011aa-4f03-4f0b-a621-xxxxxxxxxxxx    13
2020-06-18  61      FLAV RX         WINGER      BEVERAGE        100MT   0000265d-6b81-4d79-90cf-xxxxxxxxxxxx    5
2020-06-29  

Обновить:

with product_repeat_sub_query as
    (
            select customer_uuid,
                dateclosed, t.product_id, t.storeid, t.producttype, t.productsubtype, t.size, t.boardname_12,
                case
                    when ticketid = first_value(ticketid) over (partition by t.product_id, customer_uuid
                ORDER BY
                    dateclosed ASC rows between unbounded preceding and unbounded following) then 0
                    else grossreceipts
                end as product_repeat_gross, datediff(day,
                lag(dateclosed, 1) over (partition by t.boardname_12, customer_uuid, t.product_id
            ORDER BY
                dateclosed ASC,t.boardname_12, customer_uuid, t.product_id ),
                dateclosed) as product_cycle_days
            from
                daily_table.daily_sku_t t 

where (t.customer_uuid is not null) 
            and (trim(t.customer_uuid) != '')
            and (t.product_id is not null) 
            and (trim(t.product_id) != '')

)
                
    select count(*) from
    (
    select customer_uuid, dateclosed, storeid, boardname_12, producttype, productsubtype, size, product_id, product_cycle_days from daily_table.product_repeat_sub_query
    except
    select customer_uuid, dateclosed, storeid, boardname_12, producttype, productsubtype, size, product_id, product_cycle_days from product_repeat_sub_query
    );

даже после добавления всех полей из раздела в порядок и фильтрации наших нулей или пробелов в полях идентификаторов я все равно получаю каждый раз другой счетчик.


person user3476463    schedule 04.05.2021    source источник


Ответы (1)


Ваши оконные функции не имеют полностью определенных предложений order by. Вы повторили закрытые по дате значения в разделах. Это означает, что Redshift может иметь разные порядки строк для функций задержки и первого значения. Я ожидаю, что эти случайные различия в порядке приводят к изменению ваших результатов.

person Bill Weiner    schedule 04.05.2021
comment
Большое спасибо за то, что вернулись ко мне с этим советом! у вас есть предложения, как изменить запрос, чтобы результаты были согласованными? - person user3476463; 04.05.2021
comment
добавьте столбцы в свой заказ по пункту, который будет гарантировать каждый раз одинаковый порядок. Если у вас нет ни одной комбинации, которая сделает это (у вас есть дублированные строки), вы можете добавить столбцы идентификаторов, которые гарантируют, что это значение будет другим. Проблема в том, что если ваш запрос чувствителен к случайному порядку, то что он должен измерять? Если dateclosed совпадает, то какая строка должна быть возвращена lag () для достижения желаемого бизнес-результата? Я не могу помочь с этими вопросами. - person Bill Weiner; 04.05.2021
comment
Я попытался добавить все поля из раздела в порядок и отфильтровать нули или пробелы для полей идентификатора, но при каждом запуске я получаю разное количество различий. что-то мне не хватает? это то, что вы имели в виду, говоря о заказе по пункту? Я добавил обновление к своему исходному сообщению с новым кодом. Спасибо за помощь. - person user3476463; 05.05.2021
comment
Это не сработает. По определению, все столбцы в разделе by будут одинаковыми внутри раздела, поэтому их добавление в порядок by ничего не делает. Попробуйте это выбрать , count () из daily_table.daily_sku_t group by dateclosed ‹весь ваш раздел по столбцам для одной из ваших оконных функций› имеющий count (*) ›1 ;. Чтобы эти оконные функции возвращали согласованные результаты, может быть только 1 выбор порядка расположения строк в разделе. Теперь добавьте столбцы в группу по, чтобы добраться до нуля строк, где счетчик ›1. Затем вы можете добавить их в предложение order by оконной функции. - person Bill Weiner; 06.05.2021