У меня есть большая таблица хранения столбцов, которая часто обновляется. Я не загружаю обновления непосредственно в исходную таблицу, потому что в большинстве случаев это приведет к тому, что небольшое количество обновлений приведет к перестройке всего микро-раздела таблицы. Вместо этого я передаю обновления в таблицу обновлений и во время запроса объединяю оба. На практике это хорошо работает.
Так что упростите ситуацию, я представлю это в виде users_view
.
CREATE OR REPLACE VIEW users_view AS (
SELECT * FROM users
UNION ALL
SELECT * FROM user_changes
QUALIFY ROW_NUMBER() OVER(
PARTITION BY id
ORDER BY last_updated_at DESC
) = 1
)
Оба users
стол и user_changes
таблица имеет ту же схему, что и конфигурация некоторых разделов. Таким образом, я могу использовать раскрывающийся список предикатов в представлении, чтобы выбирать пользователей только в пределах правильного раздела. Давайте предположим, что это account_id
.
SELECT * FROM users_view
WHERE account_id = 1234
Но в users
стол совсем немного больше, чем user_changes
таблица, и я хотел бы добавить еще больше предикатов в users
таблица без добавления дополнительных предикатов в user_changes
стол. Почему? Потому что соответствие на users
таблица, хотя и точная на 98%, содержит ложные срабатывания/отрицательные результаты. Подробности из user_changes
необходимы для того, чтобы все исправить. Как бы это выглядело за пределами представления, это:
SELECT * FROM (
SELECT * FROM users
WHERE account_id = 1234 AND city = 'Chicago'
UNION ALL
SELECT * FROM user_changes
WHERE account_id = 1234
QUALIFY ROW_NUMBER() OVER(
PARTITION BY id
ORDER BY last_updated_at DESC
) = 1
)
WHERE account_id = 1234 AND city = 'Chicago'
Как бы отвратительно это ни выглядело, это гораздо эффективнее. Все условия могут быть применены к гораздо большему users
таблица, но только неизменные условия могут быть применены к users_changes
таблица. то есть пользователь может менять города, но пользователь не может менять учетные записи. Второй запуск всех условий после объединения заключается в том, чтобы уловить любые изменения, которые user_changes
представил.
Это громоздко писать, и тем более по мере усложнения запроса и вовлечения разработчиков запросов. Поэтому я ищу способ убедить планировщика sql пропустить удаление предикатов некоторых предикатов на моем user_changes
таблица без необходимости форматировать запрос таким образом. В идеале с видом.
PSUEDO SQL. PSUEDO SQL. PSUEDO SQL
В моих самых смелых мечтах я мог бы указать планировщику запросов, где он может использовать предикаты разделов, а где он может использовать предикаты, не относящиеся к разделам.
CREATE OR REPLACE VIEW users_view AS (
SELECT * FROM (
SELECT * FROM users
%PARTITION_PREDICATES%
%NON_PARTITION_PREDICATES%
UNION ALL
SELECT * FROM user_changes
%PARTITION_PREDICATES%
QUALIFY ROW_NUMBER() OVER(
PARTITION BY id
ORDER BY last_updated_at DESC
) = 1
)
%PARTITION_PREDICATES%
%NON_PARTITION_PREDICATES%
)
SELECT * FROM users_view
WHERE account_id = 1234 AND city = 'Chicago'
Какие-нибудь безумные идеи?