Inton, Em 11 de outubro de 2017 12:27, Ilton Junior <iltonjunio...@gmail.com> 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" <neto...@gmail.com> 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 <neto...@gmail.com> 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@listas.postgresql.org.br >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
