asset_id_value integer;
BEGIN
-- Find the asset_id based on the asset value
SELECT asset_id INTO asset_id_value
FROM asset_mapping
WHERE asset_enum = NEW.asset;
-- Check if the asset_id was found
IF asset_id_value IS NULL THEN
-- Handle the case where asset_id is not found
RAISE EXCEPTION 'Asset ID not found for asset: %', NEW.asset;
END IF;
-- Insert data into the appropriate new table with ON CONFLICT statement
IF TG_TABLE_NAME = 'raw_data' THEN
INSERT INTO raw_data_part (asset_id, time, price)
VALUES (asset_id_value, to_timestamp(NEW.time), NEW.price)
ON CONFLICT (asset_id, time) DO UPDATE
SET price = EXCLUDED.price;
ELSIF TG_TABLE_NAME = 'raw_data_depth' THEN
INSERT INTO raw_data_depth_part (asset_id, time, depth)
VALUES (asset_id_value, to_timestamp(NEW.time), NEW.depth)
ON CONFLICT (asset_id, time) DO UPDATE
SET depth = EXCLUDED.depth;
ELSIF TG_TABLE_NAME = 'raw_data_profit' THEN
INSERT INTO raw_data_profit_part (asset_id, time, profit)
VALUES (asset_id_value, to_timestamp(NEW.time), NEW.profit)
ON CONFLICT (asset_id, time) DO UPDATE
SET profit = EXCLUDED.profit;
END IF;
RETURN NULL;
END;
$$ LANGUAGE plpgsql;
Такс, апдейт ситуации, я раньше писал что обычно проц не грузится. Не в случае с COPY (тут под 100%)
Скорость записи через этот триггер 300 кб в сек с COPY
CREATE TABLE asset_mapping (
asset_enum enum_asset, asset_id serial PRIMARY KEY
);
CREATE TABLE raw_data (
asset enum_asset,
time numeric(13, 3),
price numeric(10, 4),
PRIMARY KEY (asset, time)
);
CREATE TABLE raw_data_part (
asset_id integer,
time timestamp(3),
price numeric(10, 4),
PRIMARY KEY (asset_id, time)
) PARTITION BY RANGE(asset_id);
CREATE INDEX idx_raw_data_part_asset_id ON raw_data_part (asset_id);
CREATE INDEX idx_raw_data_part_time ON raw_data_part (time);
Структура таблиц
Триггер стоит на raw_data
Как можно это дело ХОТЬ как-то ускорить?
Пытаюсь записать под ТБ данных сюда
До конца времен буду записывать
Вообще, ужэ к этой структуре как-то много вопросов. >asset_mapping ( asset_enum enum_asset, asset_id serial PRIMARY KEY ); ЗАЧЕМ?!? У вас и так enum_asset — это практически integer. Во всяком случае, можно назначить значения и привести одно к другому. (И да, ну раз ищете по enum_asset — ну, сделайте по нему индэкс.) Далее, таблица raw_data_part, судя по всему, предполагается меньшэ, чем raw_data. Почему она партицыонирована тогда? Ну, и вообще — тут ужэ важно, сколько данных в какой таблицэ есть.
raw_data по итогу имеет 0 значений :) raw_data_part по факту это и есть новый raw_data raw_data_profit и raw_data_depth это для того чтобы поставить этот триггер к другим таблицам
Знаешь как завести pg_partman на ENUM?) Я лично не знаю Поэтому сделал так) К слову, там индекс не нужен, ибо там всего 26 значений)
Вообще ни разу не работал с pg_partman. (Но уверен, что примерно такжэ, как и с integer).
Не, оно с ENUM не работает вообще Единственный способ это иметь интовую колонку (именно интовую или дейттайм, все)
Обсуждают сегодня