O que faz com que grande INSERIR mais lento e o uso do disco para explodir?
https://dba.stackexchange.com/questions/114856
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Eu tenho uma mesa de cerca de 3,1 milhões de linhas com a seguinte definição e índices:
CREATE TABLE digiroad_liikenne_elementti (
ogc_fid serial NOT NULL,
wkb_geometry geometry(Geometry,4258),
tiee_tila numeric(9,0),
vaylatyypp numeric(9,0),
toiminnall numeric(9,0),
eurooppati character varying(254),
kansalline numeric(9,0),
tyyppi numeric(9,0),
liikennevi numeric(9,0),
ens_talo_o numeric(9,0),
talonumero numeric(9,0),
ens_talo_v numeric(9,0),
oik_puol_t character varying(254),
tieosan_ta numeric(9,0),
viim_talo_ numeric(9,0),
viim_tal_1 numeric(9,0),
vas_puol_t character varying(254),
laut_tyypp numeric(9,0),
lautta_lii numeric(9,0),
inv_paalu_ numeric(19,11),
inv_paal_1 numeric(19,11),
liitalue_o numeric(9,0),
ketju_oid numeric(9,0),
tietojoukk numeric(9,0),
ajoratanum numeric(4,0),
viite_guid character varying(254),
"timestamp" date,
tiee_kunta numeric(9,0),
toissij_ti character varying(254),
viite_oid numeric(9,0),
k_elem_id numeric(9,0),
region character varying(40) DEFAULT 'REGION'::character varying,
CONSTRAINT digiroad_liikenne_elementti_pkey PRIMARY KEY (ogc_fid)
);
CREATE INDEX digiroad_liikenne_elementti_wkb_geometry_geom_idx
ON digiroad_liikenne_elementti USING gist (wkb_geometry);
CREATE INDEX dle_k_elem_id_idx
ON digiroad_liikenne_elementti USING btree (k_elem_id);
CREATE INDEX dle_ogc_fid_idx
ON digiroad_liikenne_elementti USING btree (ogc_fid);
CREATE INDEX dle_region_idx
ON digiroad_liikenne_elementti USING btree (region COLLATE pg_catalog."default");
Outra tabela com 8,6 milhões de linhas contém os atributos para as linhas da primeira tabela, as tabelas podem ser unidas com k_elem_id E region.
CREATE TABLE digiroad_segmentti (
ogc_fid serial NOT NULL,
wkb_geometry geometry(Geometry,4258),
segm_tila numeric(9,0),
tyyppi numeric(9,0),
loppupiste numeric(19,11),
alkupiste numeric(19,11),
vaikutuska numeric(9,0),
vaikutussu numeric(9,0),
vaikutusai character varying(254),
tieosanume numeric(19,11),
tienumero numeric(9,0),
dyn_arvo numeric(9,0),
dyn_tyyppi numeric(9,0),
omistaja_t numeric(9,0),
pysakki_va numeric(9,0),
pysakki_ty numeric(9,0),
pysakki_su numeric(9,0),
pysakki_ka numeric(9,0),
pysakki_yl character varying(254),
palvelu_pa numeric(9,0),
toissijain numeric(9,0),
siltataitu numeric(9,0),
rdtc_tyypp numeric(9,0),
rdtc_alaty numeric(9,0),
rdtc_paikk numeric(19,11),
rdtc_luokk numeric(9,0),
rdtc_liitt character varying(254),
palvelu_ob numeric(9,0),
ketju_oid numeric(9,0),
tietojoukk numeric(9,0),
ajoratanum numeric(4,0),
viite_guid character varying(254),
"timestamp" date,
sivusiirty numeric(19,11),
toissij_ti character varying(254),
viite_oid numeric(9,0),
k_elem_id numeric(9,0),
region character varying(40) DEFAULT 'REGION'::character varying,
CONSTRAINT digiroad_segmentti_pkey PRIMARY KEY (ogc_fid)
);
CREATE INDEX digiroad_segmentti_wkb_geometry_geom_idx
ON digiroad_segmentti USING gist (wkb_geometry);
CREATE INDEX ds_dyn_arvo_idx
ON digiroad_segmentti USING btree (dyn_arvo);
CREATE INDEX ds_dyn_tyyppi_idx
ON digiroad_segmentti USING btree (dyn_tyyppi);
CREATE INDEX ds_k_elem_id_idx
ON digiroad_segmentti USING btree (k_elem_id);
CREATE INDEX ds_ogc_fid_idx
ON digiroad_segmentti USING btree (ogc_fid);
CREATE INDEX ds_region_idx
ON digiroad_segmentti USING btree (region COLLATE pg_catalog."default");
CREATE INDEX ds_tyyppi_idx
ON digiroad_segmentti USING btree (tyyppi);
Eu estou tentando inserir as linhas da primeira tabela (com algumas modificações) em uma nova tabela:
CREATE TABLE edge_table (
id serial NOT NULL,
geom geometry,
source integer,
target integer,
km double precision,
kmh double precision DEFAULT 60,
kmh_winter double precision DEFAULT 50,
cost double precision,
cost_winter double precision,
reverse_cost double precision,
reverse_cost_winter double precision,
x1 double precision,
y1 double precision,
x2 double precision,
y2 double precision,
k_elem_id integer,
region character varying(40),
CONSTRAINT edge_table_pkey PRIMARY KEY (id)
);
Desde a execução de uma única instrução insert poderia levar um longo tempo e eu não seria capaz de ver se a instrução for preso ou algo assim, eu decidi fazê-lo em pedaços menores dentro de um loop em uma função.
A função se parece com isso:
DROP FUNCTION IF EXISTS insert_function();
CREATE OR REPLACE FUNCTION insert_function()
RETURNS VOID AS
$$
DECLARE
const_type_1 CONSTANT int := 5;
const_type_2 CONSTANT int := 11;
i int := 0;
row_count int;
BEGIN
CREATE TABLE IF NOT EXISTS edge_table (
id serial PRIMARY KEY,
geom geometry,
source integer,
target integer,
km double precision,
kmh double precision DEFAULT 60,
kmh_winter double precision DEFAULT 50,
cost double precision,
cost_winter double precision,
reverse_cost double precision,
reverse_cost_winter double precision,
x1 double precision,
y1 double precision,
x2 double precision,
y2 double precision,
k_elem_id integer,
region varchar(40)
);
batch_size := 1000;
SELECT COUNT(*) FROM digiroad_liikenne_elementti INTO row_count;
WHILE i*batch_size < row_count LOOP
RAISE NOTICE 'insert: % / %', i * batch_size, row_count;
INSERT INTO edge_table (kmh, kmh_winter, k_elem_id, region)
SELECT CASE WHEN DS.dyn_arvo IS NULL THEN 60 ELSE DS.dyn_arvo END,
CASE WHEN DS.dyn_Arvo IS NULL THEN 50 ELSE DS.dyn_arvo END,
DR.k_elem_id,
DR.region
FROM (
SELECT DLE.k_elem_id,
DLE.region,
FROM digiroad_liikenne_elementti DLE
WHERE DLE.ogc_fid >= i * batch_size
AND
DLE.ogc_fid <= i * batch_size + batch_size
) AS DR
LEFT JOIN
digiroad_segmentti DS ON
DS.k_elem_id = DR.k_elem_id
AND
DS.region = DR.region
AND
DS.tyyppi = const_type_1
AND
DS.dyn_tyyppi = const_type_2;
i := i + 1;
END LOOP;
END;
$$
LANGUAGE 'plpgsql' VOLATILE STRICT;
O problema é que ele começa a ir através dos laços muito rápido, mas, em algum ponto diminui para um rastreamento.Quando ela diminui, ao mesmo tempo, o uso do Disco no meu Windows 8, o Gerenciador de Tarefas sobe para 99%, então eu suspeito que isso está relacionado com o problema de alguma forma.
Executando o INSERT declaração sobre a sua própria com algum valor aleatório de i executa muito rapidamente, portanto, o problema parece ocorrer somente quando executá-lo no loop dentro de uma função.Aqui é o EXPLAIN (ANALYZE,BUFFERS) a partir de uma única execução:
Insert on edge_table (cost=0.86..361121.68 rows=1031 width=23) (actual time=3405.101..3405.101 rows=0 loops=1)
Buffers: shared hit=36251 read=3660 dirtied=14
-> Nested Loop Left Join (cost=0.86..361121.68 rows=1031 width=23) (actual time=61.901..3377.609 rows=986 loops=1)
Buffers: shared hit=32279 read=3646
-> Index Scan using dle_ogc_fid_idx on digiroad_liikenne_elementti dle (cost=0.43..85.12 rows=1031 width=19) (actual time=31.918..57.309 rows=986 loops=1)
Index Cond: ((ogc_fid >= 200000) AND (ogc_fid < 201000))
Buffers: shared hit=27 read=58
-> Index Scan using ds_k_elem_id_idx on digiroad_segmentti ds (cost=0.44..350.16 rows=1 width=23) (actual time=2.861..3.337 rows=0 loops=986)
Index Cond: (k_elem_id = dle.k_elem_id)
Filter: ((tyyppi = 5::numeric) AND (dyn_tyyppi = 11::numeric) AND (vaikutussu = 3::numeric) AND ((region)::text = (dle.region)::text))
Rows Removed by Filter: 73
Buffers: shared hit=31266 read=3588
Total runtime: 3405.270 ms
Meu sistema está a executar o PostgreSQL 9.3.5 no Windows 8 com 8 gb de RAM.
Eu experimentei com diferentes tamanhos de lote, fazer a consulta de formas diferentes e aumentando as variáveis de memória no Postgres configuração, mas nada parece ter realmente resolveu o problema.
Variáveis de configuração que tenham sido alterados de seus valores padrão:
shared_buffers = 2048MB
work_mem = 64MB
effective_cache_size = 6000MB
Eu gostaria de saber o que está fazendo com que isso acontece e o que poderia ser feito sobre isso.
Solução
Ao criar um nova tabela evitar o custo de escrever Write Ahead Log (WAL) completamente com CREATE TABLE AS.
Ver @Kassandry resposta para uma explicação de como WAL figuras para isso.
CREATE OR REPLACE FUNCTION insert_function()
RETURNS void AS
$func$
DECLARE
const_type_1 CONSTANT int := 5;
const_type_2 CONSTANT int := 11;
BEGIN
CREATE SEQUENCE edge_table_id_seq;
CREATE TABLE edge_table AS
SELECT nextval('edge_table_id_seq'::regclass)::int AS id
, NULL::geometry AS geom
, NULL::integer AS source
, target::integer AS target
, NULL::float8 AS km
, COALESCE(DS.dyn_arvo::float8, float8 '60') AS kmh
, COALESCE(DS.dyn_Arvo::float8, float8 '50') AS kmh_winter
, NULL::float8 AS cost
, NULL::float8 AS cost_winter
, NULL::float8 AS reverse_cost
, NULL::float8 AS reverse_cost_winter
, NULL::float8 AS x1
, NULL::float8 AS y1
, NULL::float8 AS x2
, NULL::float8 AS y2
, D.k_elem_id::integer AS k_elem_id
, D.region::varchar(40) AS region
FROM digiroad_liikenne_elementti D
LEFT JOIN digiroad_segmentti DS
ON DS.k_elem_id = D.k_elem_id
AND DS.region = D.region
AND DS.tyyppi = const_type_1
AND DS.dyn_tyyppi = const_type_2;
ALTER TABLE edge_table
ADD CONSTRAINT edge_table_pkey PRIMARY KEY(id)
, ALTER COLUMN id SET NOT NULL
, ALTER COLUMN id SET DEFAULT nextval('edge_table_id_seq'::regclass)
, ALTER COLUMN kmh SET DEFAULT 60
, ALTER COLUMN kmh_winter SET DEFAULT 50;
ALTER SEQUENCE edge_table_id_seq OWNED BY edge_table.id;
END
$func$ LANGUAGE plpgsql;
Além de evitar que o tempo para o arquivamento ou a WAL remetente para o processo de o WAL dados, isso vai realmente fazer certos comandos mais rápido, porque eles são projetados para não escrever o WAL-se
wal_leveléminimal.(Eles podem garantir a falha de segurança mais barato por fazer umafsyncno final do que escrevendo WAL.) Isso se aplica aos seguintes comandos:
CREATE TABLE AS SELECT
CREATE INDEX(e variantes, tais comoALTER TABLE ADD PRIMARY KEY)
ALTER TABLE SET TABLESPACE
CLUSTER
COPY FROM, quando a tabela de destino tem sido criado ou truncado anterior na mesma transação
Também é importante
CREATE TABLE AStorna impossível usar o pseudo-tipo deserialdiretamente.Mas uma vez que é apenas um "makro", você pode fazer tudo com a mão em vez disso:Criar a sequência, usá-lo para geraridvalores.Finalmente, defina a coluna padrão e fazer a coluna própria sequência.Relacionados:A plpgsql função de wrapper é opcional (útil para o uso repetido), você pode simplesmente executar SQL simples em uma transação:
BEGIN; ... COMMIT;Adicionar a
PRIMARY KEYdepois de inserir os dados também é mais rápido, pois a criação de o (subjacente) índice de uma peça é mais rápido do que a adição de valores de forma incremental.Você tinha um erro de lógica em seu particionamento:
WHERE DLE.ogc_fid >= i * batch_size AND DLE.ogc_fid <= i * batch_size + batch_sizeA última linha deverá sobrepor-se com a próxima partição, a linha poderia ser inserido várias vezes,levando a uma única violação de CP.O uso de
<em vez de<=seria corrigir isso - mas eu removido o particionamento completamente.Se você executar isso repetidamente, uma índice com várias colunas no
digiroad_segmentti (k_elem_id, tyyppi, dyn_tyyppi, region)pode pagar, dependendo da distribuição dos dados.
Pequenas coisas
- Não citar o idioma
plpgsqlnome, é um identificador. - Seria inútil para marcar uma função sem parâmetros como
STRICT. VOLATILEé o padrão e apenas ruído.Utilização
COALESCEpara fornecer um padrão para valores NULOS.Alguns de seus
double precision(float8) colunas pode funcionar melhor comointegerdesde que você tinha maisnumeric (9,0)em seu tabelas antigas, que provavelmente pode ser substituído com o mais barato, simplesinteger.A coluna
region varchar(40)parece um candidato para a normalização (a menos que regiões são mais originais?) Criar uma região de tabela e apenas utilizarregion_idcomo FK coluna na tabela principal.
Outras dicas
Se você apenas mudou o shared_buffers,work_mem, e effective_cache_size configuração de variáveis, então provavelmente você está ainda em execução com checkpoint_segments=3.
Neste caso, você só tem três WAL segmentos, e, como tal, precisa continuamente reciclá-los, forçando escreve para os arquivos de dados de cada vez, o que faz com que uma enorme quantidade de atividade de e/S e certamente pode abrandar o seu computador para um rastreamento.Você pode verificar os pontos de verificação do comportamento examinando o log e procurando a frase checkpoints are occurring too frequently.Você também pode olhar para o que eles estão fazendo permitindo log_checkpoints=on no postgresql.conf
Gostaria de recomendar a alteração de sua checkpoint_segments para algo maior, como 40, e o checkpoint_completion_target 0,9 para tentar suavizar o comportamento que você está descrevendo.
As configurações são descritas aqui no PostgreSQL documentação para 9.3 no Write Ahead Log a seção.=)
