Re: Travamento na criação de ín dices

Inton,

Em 11 de outubro de 2017 12:27, Ilton Junior <[email protected]>
escreveu:

> Desculpe a intromissão.. Mas está usando o concurrently? Esse índice é
> grande e dependendo do seu servidor ele vai demorar.
>

Não estou usando concurrency não. Mas poderia me indicar, com e usaria
concurrency .
Neste momento já se passaram 18 horas e ainda não foi concluido a criacao
de um unico indice.

Fiz mais algumas pesquisas e descobri que a query está com estado ativo na
tabela pg_stat_activity. Vejam o resultado completo nesta planilha do link
abaixo:

https://sites.google.com/site/goissbr/img/Resultado_pg_stat_activity-create_index.xls

A linha do comando CREATE INDEX está identificada com o fundo laranja.
EU verifiquei que o comando está com estado Ativo, mas não sei se está
aguardando algo, podem me ajudar a análisar o resultado anexo.

[]`s Neto

>
> Em 11 de out de 2017 11:25 AM, "Neto pr" <[email protected]> escreveu:
>
>> Ola Pessoal
>>
>> Ainda estou com o problema de travamento na criacão de índices. Mas
>> somente quando são razoavelmente grandes.
>>
>> Neste momento existe um índice sendo criado na tabela Lineitem (+- 10
>> Gb), e aparentemente está travado, pois iniciou-se a 7 horas atrás.
>> Eu consultei a tabela pg_locks e olha o resultado, está com bloqueio
>> ShareLock = true, que a principio é o correto para create index.
>> Mas nao sei se quem obteve o bloqueio da tabela Lineitem, foi o comando
>> Create Index, mas como só tem essa aplicacão rodando, é quase certeza que
>> sim.
>>
>> Antes de criar o índice, eu deveria definir o tipo de bloqueio de
>> transacão explicito?
>> Qualquer dica é bem vinda.
>>
>> ------------------------------------------------------------
>> -------------------------------
>> SELECT
>>       L.mode, c.relname, locktype,  l.GRANTED, l.transactionid,
>> virtualtransaction
>> FROM   pg_locks l, pg_class   c
>> where  c.oid = l.relation
>>
>> -------------- RESULT ------------------------------
>> --------------------------------
>> AccessShareLock pg_class_tblspc_relfilenode_index relation TRUE (null)
>> 3/71
>> AccessShareLock pg_class_relname_nsp_index relation TRUE (null) 3/71
>> AccessShareLock pg_class_oid_index relation TRUE (null) 3/71
>> AccessShareLock pg_class relation TRUE (null) 3/71
>> AccessShareLock pg_locks relation TRUE (null) 3/71
>> ShareLock lineitem relation TRUE (null) 21/3769
>>
>>>
>>
>> Em 10 de outubro de 2017 09:25, Neto pr <[email protected]> escreveu:
>>
>>> Olá pessoal
>>>
>>> Meu cenário é: postgresql 10, Processador Xeon 2.8GHz/4-core- 8gb Ram,
>>> SO Debian 8.
>>>
>>> Ao criar indices em uma tabela de +- 10GB de dados o SGBD trava (eu
>>> acho), pois mesmo depois de esperar 10 horas não houve retorno do comando.
>>> Aconteceu criando índices Hash e índices B+ tree. No entanto, para algumas
>>> colunas, foi com sucesso (L_RETURNFLAG, L_PARTKEY).
>>> O ambiente de dados que estou me referindo é a tabela LINEITEM
>>> (benchmark TPC-H) do link [1] abaixo. As colunas/indices que travaram na
>>> criação foram:
>>> * Índice Hash em: L_TAX
>>> ( Índice Btree em: L_RECEIPTDATE.
>>>
>>> Se alguém tiver uma dica de como proceder para agilizar a criação de
>>> índices, de forma que seja concluído com sucesso. Sei que o PostgreSQL 10
>>> tem alguns recursos de paralelismo e como meu servidor é dedicado somente
>>> para o SGBD, será que alterar os parâmetros: force_parallel_mode,
>>> max_parallel_workers_per_gather poderia agilizar a criação de índices
>>> em tabelas grandes?
>>> Qualquer dica é bem vinda.
>>>
>>> DDL TABELA:
>>> CREATE TABLE LINEITEM (
>>> L_ORDERKEY BIGINT NOT NULL, -- references O_ORDERKEY
>>> L_PARTKEY BIGINT NOT NULL, -- references P_PARTKEY (compound fk to
>>> PARTSUPP)
>>> L_SUPPKEY BIGINT NOT NULL, -- references S_SUPPKEY (compound fk to
>>> PARTSUPP)
>>> L_LINENUMBER INTEGER,
>>> L_QUANTITY DECIMAL,
>>> L_EXTENDEDPRICE DECIMAL,
>>> L_DISCOUNT DECIMAL,
>>> L_TAX DECIMAL,
>>> L_RETURNFLAG CHAR(1),
>>> L_LINESTATUS CHAR(1),
>>> L_SHIPDATE DATE,
>>> L_COMMITDATE DATE,
>>> L_RECEIPTDATE DATE,
>>> L_SHIPINSTRUCT CHAR(25),
>>> L_SHIPMODE CHAR(10),
>>> L_COMMENT VARCHAR(44),
>>>         PRIMARY KEY (L_ORDERKEY, L_LINENUMBER)
>>> 1- http://kejser.org/wp-content/uploads/2014/06/image_thumb2.png
>>>
>>> []'s Neto
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Livre
>>> de vírus. www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>.
>>>
>>> <#m_-2778354492096473418_m_1203795175890998041_m_1708445859716377615_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>>
>>
>>
>> _______________________________________________
>> pgbr-geral mailing list
>> pgbr-geral-b/[email protected]
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral-b/[email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral