Hola! Есть возможность как-то реально оценить сколько ресурсов будет требовать какое-то

sql выражение?

Есть задача из view core_order_events сделать таблицу
Я это делала как показано ниже, потом дропнула view и переименовала таблицу
CREATE TABLE core_order_events_new AS SELECT * FROM core_order_events ORDER BY order_id

Лид топит за то, что бы создать сначала таблицу, потом заполнить так
INSERT INTO core_order_events_new(here goes list of columns)
SELECT * FROM core_order_events;

Может кто сравнивал или уже знает... Что из этого эффективнее? Есть прям сильный перекос в какую нибудь из сторон?

Должно быть одинаково

А есть вообще инструмент, которым можно было бы оценить?

Создайте тестовую БД да проверьте )

Да и то и другое работает. Второй способ я проверю. Меня интересуют 2 вещи 1. Есть ли реальный инструмент, которым можно оценить сколько ресурсов это использует. Что бы к лиду идти точными данными 2. Может у какогото из способов есть подводные камни, о которых я могу не знать

1. Нет, только тест. 2. Теоретически возможно, что создание таблицы в "длинной транзакции" с копированием данных чего-нибудь там залочит. Надо смотреть документацию и, возможно, исходники - как это реализовано.

Спасибо

Конечно. https://magazine.tagheuer.com/en/2023/06/29/only-watch-2023-the-new-tag-heuer-monaco-split-seconds-chronograph/

А зачем вы order by вставили?

Спасибо

Это фигня. Можно убрать. Хотела что бы id и order_id были возрастающими. Просто во вью order by order_id desc

Есть определённые нюансы которые create-table-as-select передать не сможет postgres=# create table test1(txt text); CREATE TABLE postgres=# alter table test1 alter column txt set storage plain; ALTER TABLE postgres=# insert into test1 select repeat(md5(a::text),160) from generate_series(1,100) a; INSERT 0 100 postgres=# create table test2 as select * from test1; SELECT 100 postgres=# \dt+ test* List of relations Schema | Name | Type | Owner | Persistence | Access method | Size | Description --------+-------+-------+----------+-------------+---------------+--------+------------- public | test1 | table | postgres | permanent | heap | 832 kB | public | test2 | table | postgres | permanent | heap | 24 kB | (2 rows) postgres=#

А что он мог не передать аж на 800+ kb? Я очень извиняюсь за глупые вопросы. Правда хотелось бы знать что под капотом

Данные везде одинаковые. Для поля txt в таблице test1 не разрешено сжатие. А в таблице test2 соответственно разрешено.

Поняла. Спасибо

У автора view

В PG вроде нет разницы, а в Greenplum с CTAS всякие интересные баги исторически бывали (к 7 версии вроде всё пофиксят) - там аккуратно надо Ну и ещё надо помнить, что в CTAS такой же INSERT выполняется с такими же блокировками. Видел коллег, которые удивлялись, что CTAS им блокирует DDL на таблицах-источниках (как и любой INSERT/UPDATE/DELETE)

Таблица-источник благо вью 🤡