Re: [pgbr-geral] tablespace temporária

[Neto pr]

Em 15 de janeiro de 2018 03:31, Flavio Henrique Araque Gurgel
<fha...@gmail.com> escreveu:
>
>
> Em seg, 15 de jan de 2018 às 12:12, Neto pr <neto...@gmail.com> escreveu:
>>
>> Ola pessoal,
>> Como eu posso descobrir onde está a minha tablespace temporaria no
>> Postgresql 10.1, uso Linux Debian 8?
>>
>> No PSQL com o comando \db+ nao mostra a localizacao, veja:
>>
>> bdteste=# \db+
>>  List of tablespaces
>> Name|  Owner   |Location| Access
>> privileges | Options |  Size  | Description
>>
>> +--++---+-++-
>>  pg_default | postgres |
>> |   | | 21 MB  |
>>  pg_global  | postgres |
>> |   | | 573 kB |
>>  tblpgssd| postgres | /media/discossd/dados/pg101ssd |
>>   | | 206 GB |
>> (3 rows)
>>
>> Meu Postgresql foi instalado compilando o mesmo em um disco SSD. Eu
>> acreditava que a tablespace temporaria seria instalada no diretorio
>> data, onde está o arquivo postgresql.conf, no meu caso está em
>> /media/discossd/opt/pg10/data  , estou certo?
>> Qual seria a temporária, pg_default ou pg_global ?
>>
> Se você nada fez na sua instalação, estará em pg_default.
> Para ter certeza, o comando:
> show temp_tablespaces;
> Retorna vazio caso esteja no default. Está na documentação oficial aqui:
> https://www.postgresql.org/docs/current/static/runtime-config-client.html#GUC-TEMP-TABLESPACES
>

Retornou vazio, entao se meu arquivo postgreql.conf (onde eu iniciei o
banco)  está em /media/discossd/opt/pg10/data/ a pg_default estará lá?


> Pronto, pode responder lá na lista internacional onde estou acompanhando seu
> outro problema. Tem semi-deuses te ajudando por lá.

Flavio, sim estou tentando desvendar aquele problema... digo que o
semi-deuses do postgres estao em pgsql-committers e  pgsql-hackers...
[]s
Neto


>
> []s
> Flavio Gurgel
>
>
>
>
> ___
> 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] tablespace temporária

[Neto pr]

Ola pessoal,
Como eu posso descobrir onde está a minha tablespace temporaria no
Postgresql 10.1, uso Linux Debian 8?

No PSQL com o comando \db+ nao mostra a localizacao, veja:

bdteste=# \db+
 List of tablespaces
Name|  Owner   |Location| Access
privileges | Options |  Size  | Description
+--++---+-++-
 pg_default | postgres |
|   | | 21 MB  |
 pg_global  | postgres |
|   | | 573 kB |
 tblpgssd| postgres | /media/discossd/dados/pg101ssd |
  | | 206 GB |
(3 rows)

Meu Postgresql foi instalado compilando o mesmo em um disco SSD. Eu
acreditava que a tablespace temporaria seria instalada no diretorio
data, onde está o arquivo postgresql.conf, no meu caso está em
/media/discossd/opt/pg10/data  , estou certo?
Qual seria a temporária, pg_default ou pg_global ?

[]'s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] postgresql.conf não encontrado

[Neto pr]

Em 3 de novembro de 2017 15:58, Neto pr <neto...@gmail.com> escreveu:

>
> Em 3 de novembro de 2017 13:54, Flavio Henrique Araque Gurgel <
> fha...@gmail.com> escreveu:
>
>>
>>>>
>>> Vi no log que nao estava encontrando as bibliotecas.  Apos isso,
>>> instalei os pacote conforme tutorial abaixo  e mesmo assim nao encontrava.
>>> Entao copiei  e colei na pasta /usr/lib/postgresql/9.6/lib/ as
>>> bibliotecas  (arquivos *.so).
>>> Agora o erro que ocorre e' que a de versao incompativel, ou seja, versao
>>> do SGBD e' 9.6  e a biblioteca e' da versao 10.0.
>>> O estranho e' que segui o tutuorial e o link que passaram estava
>>> informando que era da versao 9.6, vejam o link do arquivo o  log de erro.
>>> Ja a outra biblioteca da erro de copy symbol.
>>>
>>> == Log erro 
>>> 2017-11-03 12:00:44.445 BRST [1610] FATAL:  could not access file
>>> "pg_stat_kcache": No such file or directory
>>> 2017-11-03 12:00:44.445 BRST [1610] LOG:  database system is shut down
>>> 2017-11-03 12:14:52.216 BRST [1672] FATAL:  incompatible library
>>> "/usr/lib/postgresql/9.6/lib/pg_stat_kcache.so": version mismatch
>>> 2017-11-03 12:14:52.216 BRST [1672] DETAIL:  Server is version 9.6,
>>> library is version 10.0.
>>> 2017-11-03 12:14:52.216 BRST [1672] LOG:  database system is shut down
>>> 2017-11-03 12:18:56.311 BRST [1729] FATAL:  could not load library
>>> "/usr/lib/postgresql/9.6/lib/pg_qualstats.so": /usr/lib/postgresq
>>> l/9.6/lib/pg_qualstats.so: undefined symbol: copyObjectImpl
>>> 2017-11-03 12:18:56.311 BRST [1729] LOG:  database system is shut down
>>> 2017-11-03 12:27:10.895 BRST [1799] FATAL:  incompatible library
>>> "/usr/lib/postgresql/9.6/lib/pg_stat_kcache.so": version mismatch
>>> 2017-11-03 12:27:10.895 BRST [1799] DETAIL:  Server is version 9.6,
>>> library is version 10.0.
>>>
>>
>> Bom verifique os seus repositórios configurados em:
>> /etc/apt/sources.list
>> e
>> /etc/apt/sources.list.d/*
>>
>>
> Como estou fazendo teste em uma vm. Fiz uma nova VM, com instalacao do
> Postgresql 10 do zero..
>
>
>> Desinstale as diversas extensões relacionadas ao PoWA e reinstale com as
>> versões corretas usando apt.
>> Eu tenho aqui, funcional, tudo instalado a partir de apt.postgresql.org,
>> inclusive o servidor PostgreSQL, versão 9.6,  sem problemas.
>> Pode ser que você tenha configurado o repositório da versão 10 também, o
>> apt vai usar a versão mais nova para os pacotes que não tem o número da
>> versão explícito no nome.
>> Você pode usar apt-pinning caso queira manter o repositório da versão 10,
>> mas não vejo porque no seu caso.
>>
>>
> Agora somente 1 biblioteca esta dando erro.
> Ao habilitar
> shared_preload_libraries = 'pg_stat_statements, powa,
> pg_stat_kcache, pg_qualstats'
>
> Esta dando erro  somente na pg_qualstats, pois quando retiro ela de
> shared_preload o SGBD funciona.
>
> Pior que agora, o log de erro não está ajudando, somente informa "aborting
> any active transactions"
> Veja abaixo que no momento em que executo o psql, foi na linha com seta.
> Alguem sabe algum outro lugar que daria para ver a causa do erro, da
> biblioteca pg_qualstats.??
> 
> -
>
>
Pessoal
Agradeco, reinstalei a biblioteca PG_QUALSTATS e funcionou.

[]`s Net



>
> []s
>> Flavio Gurgel
>>
>>
>> ___
>> 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

Re: [pgbr-geral] postgresql.conf não encontrado

[Neto pr]

Em 3 de novembro de 2017 13:54, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

>
>>>
>> Vi no log que nao estava encontrando as bibliotecas.  Apos isso, instalei
>> os pacote conforme tutorial abaixo  e mesmo assim nao encontrava.
>> Entao copiei  e colei na pasta /usr/lib/postgresql/9.6/lib/ as
>> bibliotecas  (arquivos *.so).
>> Agora o erro que ocorre e' que a de versao incompativel, ou seja, versao
>> do SGBD e' 9.6  e a biblioteca e' da versao 10.0.
>> O estranho e' que segui o tutuorial e o link que passaram estava
>> informando que era da versao 9.6, vejam o link do arquivo o  log de erro.
>> Ja a outra biblioteca da erro de copy symbol.
>>
>> == Log erro 
>> 2017-11-03 12:00:44.445 BRST [1610] FATAL:  could not access file
>> "pg_stat_kcache": No such file or directory
>> 2017-11-03 12:00:44.445 BRST [1610] LOG:  database system is shut down
>> 2017-11-03 12:14:52.216 BRST [1672] FATAL:  incompatible library
>> "/usr/lib/postgresql/9.6/lib/pg_stat_kcache.so": version mismatch
>> 2017-11-03 12:14:52.216 BRST [1672] DETAIL:  Server is version 9.6,
>> library is version 10.0.
>> 2017-11-03 12:14:52.216 BRST [1672] LOG:  database system is shut down
>> 2017-11-03 12:18:56.311 BRST [1729] FATAL:  could not load library
>> "/usr/lib/postgresql/9.6/lib/pg_qualstats.so": /usr/lib/postgresq
>> l/9.6/lib/pg_qualstats.so: undefined symbol: copyObjectImpl
>> 2017-11-03 12:18:56.311 BRST [1729] LOG:  database system is shut down
>> 2017-11-03 12:27:10.895 BRST [1799] FATAL:  incompatible library
>> "/usr/lib/postgresql/9.6/lib/pg_stat_kcache.so": version mismatch
>> 2017-11-03 12:27:10.895 BRST [1799] DETAIL:  Server is version 9.6,
>> library is version 10.0.
>>
>
> Bom verifique os seus repositórios configurados em:
> /etc/apt/sources.list
> e
> /etc/apt/sources.list.d/*
>
>
Como estou fazendo teste em uma vm. Fiz uma nova VM, com instalacao do
Postgresql 10 do zero..


> Desinstale as diversas extensões relacionadas ao PoWA e reinstale com as
> versões corretas usando apt.
> Eu tenho aqui, funcional, tudo instalado a partir de apt.postgresql.org,
> inclusive o servidor PostgreSQL, versão 9.6,  sem problemas.
> Pode ser que você tenha configurado o repositório da versão 10 também, o
> apt vai usar a versão mais nova para os pacotes que não tem o número da
> versão explícito no nome.
> Você pode usar apt-pinning caso queira manter o repositório da versão 10,
> mas não vejo porque no seu caso.
>
>
Agora somente 1 biblioteca esta dando erro.
Ao habilitar
shared_preload_libraries = 'pg_stat_statements, powa,
pg_stat_kcache, pg_qualstats'

Esta dando erro  somente na pg_qualstats, pois quando retiro ela de
shared_preload o SGBD funciona.

Pior que agora, o log de erro não está ajudando, somente informa "aborting
any active transactions"
Veja abaixo que no momento em que executo o psql, foi na linha com seta.
Alguem sabe algum outro lugar que daria para ver a causa do erro, da
biblioteca pg_qualstats.??
-

017-11-03 15:41:02.323 BRST [3324] QUERY:  SELECT powa_take_snapshot()
2017-11-03 15:41:02.325 BRST [3269] LOG:  worker process: powa (PID 3324)
exited with exit code 1
2017-11-03 15:41:12.338 BRST [3325] LOG:  POWA connected to database powa
2017-11-03 15:41:25.772 BRST [3317] postgres@powa ERROR:  This module can
only be loaded via shared_preload_libraries
2017-11-03 15:41:25.772 BRST [3317] postgres@powa STATEMENT:  CREATE
EXTENSION pg_qualstats;
executei psql com usuario postgres   > 2017-11-03 15:43:02.887
BRST [3269] LOG:  received fast shutdown request
2017-11-03 15:43:02.947 BRST [3269] LOG:  aborting any active transactions
2017-11-03 15:43:02.949 BRST [3325] FATAL:  terminating background worker
"powa" due to administrator command
2017-11-03 15:43:02.951 BRST [3269] LOG:  worker process: powa (PID 3325)
exited with exit code 1
2017-11-03 15:43:02.953 BRST [3269] LOG:  worker process: logical
replication launcher (PID 3277) exited with exit code 1
2017-11-03 15:43:02.956 BRST [3271] LOG:  shutting down
2017-11-03 15:43:04.599 BRST [3269] LOG:  database system is shut down
2017-11-03 15:43:04.788 BRST [3354] LOG:  listening on IPv6 address "::1",
port 5432
2017-11-03 15:43:04.788 BRST [3354] LOG:  listening on IPv4 address
"127.0.0.1", port 5432
2017-11-03 15:43:04.822 BRST [3354] LOG:  listening on Unix socket
"/var/run/postgresql/.s.PGSQL.5432"
pg_ctl: could not start server
Examine the log output.
postgres@vmhp110deb8:/home/user1$


[]s
> Flavio Gurgel
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
___
pgbr-geral 

Re: [pgbr-geral] postgresql.conf não encontrado

[Neto pr]

Em 3 de novembro de 2017 10:52, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

>
>
> Em sex, 3 de nov de 2017 às 13:44, Neto pr <neto...@gmail.com> escreveu:
>
>> Daniel,
>> sim estava no diretorio /etc/postgresql. Sempre instalei compilando os
>> fontes, por isso me perdi nessa.
>>
>> Outro problema que está ocorrendo com este parametro do postgresql.conf
>>
>> shared_preload_libraries = 'pg_stat_statements, powa, pg_stat_kcache,
>> pg_qualstats'
>>
>> Ao colocar as duas bibliotecas abaixo o  SGBD não sobe. Ja tentei colocar
>> somente 1 delas, mas realmente as duas dão erro.
>> - pg_stat_kcache
>> - pg_qualstats
>>
>>
> Se alguém tiver alguma dica, será bem vinda.
>>
>
> Eu tenho duas dicas:
> Dica 1 - pare de fazer top post, você não é mais novato
>

OK, Sobre top post, mal ha'bito


> Dica 2 - mande a mensagem de erro que sai
>
>
Vi no log que nao estava encontrando as bibliotecas.  Apos isso, instalei
os pacote conforme tutorial abaixo  e mesmo assim nao encontrava.
Entao copiei  e colei na pasta /usr/lib/postgresql/9.6/lib/ as bibliotecas
(arquivos *.so).
Agora o erro que ocorre e' que a de versao incompativel, ou seja, versao do
SGBD e' 9.6  e a biblioteca e' da versao 10.0.
O estranho e' que segui o tutuorial e o link que passaram estava informando
que era da versao 9.6, vejam o link do arquivo o  log de erro.  Ja a outra
biblioteca da erro de copy symbol.

== Log erro 
2017-11-03 12:00:44.445 BRST [1610] FATAL:  could not access file
"pg_stat_kcache": No such file or directory
2017-11-03 12:00:44.445 BRST [1610] LOG:  database system is shut down
2017-11-03 12:14:52.216 BRST [1672] FATAL:  incompatible library
"/usr/lib/postgresql/9.6/lib/pg_stat_kcache.so": version mismatch
2017-11-03 12:14:52.216 BRST [1672] DETAIL:  Server is version 9.6, library
is version 10.0.
2017-11-03 12:14:52.216 BRST [1672] LOG:  database system is shut down
2017-11-03 12:18:56.311 BRST [1729] FATAL:  could not load library
"/usr/lib/postgresql/9.6/lib/pg_qualstats.so": /usr/lib/postgresq
l/9.6/lib/pg_qualstats.so: undefined symbol: copyObjectImpl
2017-11-03 12:18:56.311 BRST [1729] LOG:  database system is shut down
2017-11-03 12:27:10.895 BRST [1799] FATAL:  incompatible library
"/usr/lib/postgresql/9.6/lib/pg_stat_kcache.so": version mismatch
2017-11-03 12:27:10.895 BRST [1799] DETAIL:  Server is version 9.6, library
is version 10.0.
2017-11-03 12:27:

--
PoWA Documentation, Release 3.1.0
On Debian:
apt-get install postgresql-server-dev-9.6 postgresql-contrib-9.6
Installation
Download powa-archivist latest release:
wget https://github.com/dalibo/powa-archivist/archive/REL_3_1_0.tar.gz
A convenience script is offered to build every project that PoWA can take
advantage of:
#!/bin/bash
# This script is meant to install every PostgreSQL extension compatible with
# PoWA.

--> AQUUIII --->   wget
https://github.com/dalibo/pg_qualstats/archive/1.0.2.tar.gz -O pg_
˓
→
qualstats-1.0.2.tar.gz
tar zxvf pg_qualstats-1.0.2.tar.gz
cd pg_qualstats-1.0.2
(make && sudo make install)  > /dev/null 2>&1
cd ..
rm pg_qualstats-1.0.2.tar.gz
rm pg_qualstats-1.0.2 -rf
--> AQUUIII --->wget
https://github.com/dalibo/pg_stat_kcache/archive/REL2_0_3.tar.gz -O pg_
˓
→
stat_kcache-REL2_0_3.tar.gz
tar zxvf pg_stat_kcache-REL2_0_3.tar.gz
cd pg_stat_kcache-REL2_0_3
(make && sudo make install)  > /dev/null 2>&1
cd ..
rm pg_stat_kcache-REL2_0_3.tar.gz
rm pg_stat_kcache-REL2_0_3 -rf
(make && sudo make install)  > /dev/null 2>&1
echo ""
echo "You should add the following line to your postgresql.conf:"
echo ''
echo "shared_preload_libraries='pg_stat_statements,powa,pg_stat_kcache,pg_
˓
→
== FIM ==




> Aí a gente vem com mais dicas quentinhas.
>
> []s
> Flavio Gurgel
>
> ___
> 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

Re: [pgbr-geral] postgresql.conf não encontrado

[Neto pr]

Daniel,
sim estava no diretorio /etc/postgresql. Sempre instalei compilando os
fontes, por isso me perdi nessa.

Outro problema que está ocorrendo com este parametro do postgresql.conf

shared_preload_libraries = 'pg_stat_statements, powa, pg_stat_kcache,
pg_qualstats'

Ao colocar as duas bibliotecas abaixo o  SGBD não sobe. Ja tentei colocar
somente 1 delas, mas realmente as duas dão erro.
- pg_stat_kcache
- pg_qualstats

Se alguém tiver alguma dica, será bem vinda.

[]`s Neto









Em 3 de novembro de 2017 05:07, Daniel Luiz da Silva <
daniel.si...@ipm.com.br> escreveu:

>
>
> --
> *De: *"Neto pr" <neto...@gmail.com>
> *Para: *"Comunidade PostgreSQL Brasileira" <pgbr-geral@listas.postgresql.
> org.br>
> *Enviadas: *Sexta-feira, 3 de novembro de 2017 9:31:54
> *Assunto: *[pgbr-geral] postgresql.conf não encontrado
>
> Olá
>
> Estava tentando instalar o postgresql via este tutorial [1] para utilizar
> a ferramenta para bd Powa.
>
> Uso  S.O. debian 8 Jessie.
>
> Executei:
>   apt-get install postgresql-9.6 postgresql-client-9.6
> postgresql-contrib-9.6
>   apt-get install postgresql-9.6-powa
>
> Até ai tudo bem, o SGBD subiu e consigo criar tabelas etc.
>
> Mas não estou encontrando onde está o arquivo postgresql.conf.
> Tentei pesquisar utilizando locate postgresql.conf, más não encontra,
> desconfio que não foi criado.
> Preciso adicionar algumas bibliotecas no parametro:
> shared_preload_libraries
>
> Alguém já instalou o postgresql desta forma, e poderia informar onde pode
> estar o arquivo postgresql.conf, ou outro para configurar o parametro
> shared_preload_libraries ?
>
> [1] http://powa.readthedocs.io/en/latest/quickstart.html
>
> []`s Neto
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
> --
>
> Neto,
>
> antes de utilizar o locate, faça atualização do dicionário de arquivos no
> linux, com comando "updatedb".
> Sobre o postgresql.conf, ele estará dentro do diretório
> /etc/postgresql/... caso não foi modificado na instalação.
>
> Obrigado.
>
> ___
> 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] postgresql.conf não encontrado

[Neto pr]

Olá

Estava tentando instalar o postgresql via este tutorial [1] para utilizar a
ferramenta para bd Powa.

Uso  S.O. debian 8 Jessie.

Executei:
  apt-get install postgresql-9.6 postgresql-client-9.6
postgresql-contrib-9.6
  apt-get install postgresql-9.6-powa

Até ai tudo bem, o SGBD subiu e consigo criar tabelas etc.

Mas não estou encontrando onde está o arquivo postgresql.conf.
Tentei pesquisar utilizando locate postgresql.conf, más não encontra,
desconfio que não foi criado.
Preciso adicionar algumas bibliotecas no parametro: shared_preload_libraries

Alguém já instalou o postgresql desta forma, e poderia informar onde pode
estar o arquivo postgresql.conf, ou outro para configurar o parametro
shared_preload_libraries ?

[1] http://powa.readthedocs.io/en/latest/quickstart.html

[]`s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Travamento na criação de índices

[Neto pr]

Em 11 de outubro de 2017 20:46, Ilton Junior <iltonjunio...@gmail.com>
escreveu:

> Amigão! Utilize da seguinte forma:
> "Create index concurrently..."
>

Eu estou usando linux, mas esse comando é executado dentro de uma aplicacao
JAVA e deverá continuar assim, pela regras internas.

Eu testei a criacão usando o concurrency e pelo que vi o índice já apareceu
no resultado da consulta, pois antes, o indice nem aparecia no resultado,
somente a tabela Lineitem:

SELECT
  L.mode, c.relname, locktype,  l.GRANTED, l.transactionid,
virtualtransaction
FROM   pg_locks l, pg_class   c
where  c.oid = l.relation

tela resultado apos concurrency:https://i.stack.imgur.com/htzIY.jpg

Agora, estou aguardando terminar a criacão do índice.



> Se estiver usando Linux indico você a executar tal comando diretamente do
> bash do seu servidor, dessa forma as tabelas não são bloqueadas, estamos
> falando de um índice relativamente grande, então, vale também fazer um
> tunning, da uma lida sobre "indice condicional", dependendo dos dados seja
> o seu caso.
>
> Obs:
> CONCURRENTLY
>
> When this option is used, PostgreSQL will build the index without taking
> any locks that prevent concurrent inserts, updates, or deletes on the
> table; whereas a standard index build locks out writes (but not reads) on
> the table until it's done. There are several caveats to be aware of when
> using this option — see Building Indexes Concurrently
> <https://www.postgresql.org/docs/9.1/static/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY>
>
> [ ]`s Neto


> Em 11 de out de 2017 8:20 PM, "Euler Taveira" <eu...@timbira.com.br>
> escreveu:
>
>> Em 11 de outubro de 2017 20:04, Neto pr <neto...@gmail.com> escreveu:
>>
>>>
>>> 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.
>>>
>>> Você não informou o sistema operacional mas se for Linux:
>>
>> # strace -p 1234
>>
>> onde 1234 é o PID da conexão (que você pode obter no pg_stat_activity).
>> Se for outro sistema operacional tais como FreeBSD, AIX ou Solaris, use
>> truss.
>>
>>
>> --
>>Euler Taveira   Timbira -
>> http://www.timbira.com.br/
>>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>> <http://www.timbira.com.br>
>>
>> ___
>> 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

Re: [pgbr-geral] Travamento na criação de índices

[Neto pr]

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
>>>
>>

Re: [pgbr-geral] Travamento na criação de índices

[Neto pr]

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_source=link_campaign=sig-email_content=webmail>
>  Livre
> de vírus. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>.
> <#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] Travamento na criação de índices

[Neto pr]

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


Livre
de vírus. www.avast.com
.
<#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

Re: [pgbr-geral] Instalar extensão manualmente

[Neto pr]

Boa...

Funcionou agora, depois de exportar o PATH. Thanks

Nem precisei colocar o arquivo hypo.so no lib, pois o comando make install
fez isso para mim:
/usr/bin/install -c -m 755  hypopg.so
'/opt/pgv10/lib/postgresql/hypopg.so'

  saída completa shell   =
root@hp2ml110deb:/home/user1/Downloads/codigo/hypopg-master# export
PATH=/opt/pgv10/bin:$PATH
root@hp2ml110deb:/home/user1/Downloads/codigo/hypopg-master# USE_PGXS=1
make install
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-O2 -fPIC -I. -I./ -I/opt/pgv10/include/postgresql/server
-I/opt/pgv10/include/postgresql/internal  -D_GNU_SOURCE   -c -o hypopg.o
hypopg.c
hypopg.c: In function ‘hypopg_get_indexdef’:
hypopg.c:1601:21: warning: ‘entry’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
  if (!entry || entry->oid != indexid)
 ^
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-O2 -fPIC -I. -I./ -I/opt/pgv10/include/postgresql/server
-I/opt/pgv10/include/postgresql/internal  -D_GNU_SOURCE   -c -o
hypopg_import.o hypopg_import.c
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
-O2 -fPIC -shared -o hypopg.so hypopg.o hypopg_import.o -L/opt/pgv10/lib
-Wl,--as-needed -Wl,-rpath,'/opt/pgv10/lib',--enable-new-dtags
/bin/mkdir -p '/opt/pgv10/lib/postgresql'
/bin/mkdir -p '/opt/pgv10/share/postgresql/extension'
/bin/mkdir -p '/opt/pgv10/share/postgresql/extension'
/usr/bin/install -c -m 755  hypopg.so '/opt/pgv10/lib/postgresql/hypopg.so'
/usr/bin/install -c -m 644 .//hypopg.control
'/opt/pgv10/share/postgresql/extension/'
/usr/bin/install -c -m 644 .//hypopg--1.1.0.sql
'/opt/pgv10/share/postgresql/extension/'
root@hp2ml110deb:/home/user1/Downloads/codigo/hypopg-master#




Em 7 de outubro de 2017 15:38, Euler Taveira <eu...@timbira.com.br>
escreveu:

> Em 7 de outubro de 2017 19:28, Neto pr <neto...@gmail.com> escreveu:
> > Eu instalei o Posgresql versao 10 (stable) através do pacote fonte
> > (compilando manualmente) no diretório  opt/pgv10/.. no meu SO LInux
> Debian
> > 8.
> >
> > Eu gostaria de usar a extensão HIPOPG [1],[2] para habilitar a criacão de
> > índices hipotéticos no postgresql.
> >
> > Pelo que vi, tem que ter o pacote Dev do postgresql, mas acredito que
> minha
> > instalacão nao tenha isso (eu acho).
> >
> > Tentei baixar a extensão arquivo.zip mas nao tem como proceder a
> compilacão
> > e instalacão  (com make e make install), pois da a seguinte mensagem:
> > make: pg_config: Command not found
> > make: Nothing to be done for 'all'.
> >
> Como o pg_config não está no seu PATH, você precisar definir o PATH.
>
> $ export PATH=/opt/pgv10/bin:$PATH
> $ cd hipopg
> $ USE_PGXS=1 make install
>
> Certifique-se que o arquivo hypo.so esteja no diretório lib da
> instalação do PostgreSQL. Depois disso é só fazer o CREATE EXTENSION
> no banco de dados desejado.
>
>
> --
>Euler Taveira   Timbira -
> http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> 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] Instalar extensão manualmente

[Neto pr]

Ola Pessoal

Eu instalei o Posgresql versao 10 (stable) através do pacote fonte
(compilando manualmente) no diretório  opt/pgv10/.. no meu SO LInux Debian
8.

Eu gostaria de usar a extensão HIPOPG [1],[2] para habilitar a criacão de
índices hipotéticos no postgresql.

Pelo que vi, tem que ter o pacote Dev do postgresql, mas acredito que minha
instalacão nao tenha isso (eu acho).

Tentei baixar a extensão arquivo.zip mas nao tem como proceder a compilacão
e instalacão  (com make e make install), pois da a seguinte mensagem:
make: pg_config: Command not found
make: Nothing to be done for 'all'.

Nesse arquivo .zip que baixei tem os arquivos: HANGELOG.md
hypopg--1.0.0.sql  hypopg.control   hypopg_import.h  META.json  test
typedefs.listexpected  hypopg.chypopg_import.c
Makefile README.md  TODO.md

Em tutoriais na internet, falam para instalar via apt-get, mas como
instalei manualmente acredito que nao irá funcionar.

Tentei executar o comando:
   create extension hypopg; no psql, mas deu a mensagem abaixo, mesmo eu
colocando os arquivos hypopg.control em
opt/pgv10/share/postgresql/extension/

ERROR:  could not access file "$libdir/hypopg": No such file or
directory

Alguém saberia informar como instalar manualmente uma extensão e se teria
que ter o pacote -dev mesmo e como instalaria esse pacote.

1 -https://github.com/dalibo/hypopg/blob/master/README.md#installation
2 -
https://rjuju.github.io/postgresql/2015/07/02/how-about-hypothetical-indexes.html

Abcs
[]'s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Ferramentas p/ recomendação de índices

[Neto pr]

Olá Pessoal

Estou pesquisando sobre Ferramentas para Recomendação de Índices
(Index-Advisor) para ser aplicados em consultas SQLs.
A principio encontrei estes:

- EnterpriseDB -
https://www.enterprisedb.com/docs/en/9.5/asguide/EDB_Postgres_Advanced_Server_Guide.1.56.html
- Powa http://dalibo.github.io/powa/

Alguém saberia de outras ferramentas para este propósito. Caso já tenham
usados estas acima, se puderem informar o que acharam.

Grato
[]'s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Btree Level

[Neto pr]

Bom dia a todos

Preciso descobrir a altura de um índice B-tree (nível do nó folha mais
distante da raiz).

Tentei achar esse dado nas views PG_INDEXES e PG_CLASS, más não encontrei.
Alguém sabe se o Postgresql grava essa informacão, referente a altura da
árvore do índice?

Att
Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Cálculo de tempo em Exp Analyze

[Neto pr]

Pessoal, desculpe, mas na conta que fiz, cometi um erro, não considei
o . (ponto) como separador decimal, como é feito no Inglês.
Mas mesmo assim o resultado final da mensagem anterior é próximo a 182
minutos. Ou seja

419.113/1000 = 0.41 segundos  * 26469 (loops) = 11093.50 segundos or 184 minutos

Depois de analisar, vi que em alguns lugares do plano, está utilizando
Paralelismo. Será que isto explica porque o valor final em minutos
gasto para percorrer um índice (184 minutos) é maior que o tempo total
da query (66 minutos)?

Em 7 de setembro de 2017 20:02, Neto pr <neto...@gmail.com> escreveu:
> Saudacões,
> Estou tentando interpretar um Explain Analyze, mas travei nisso:
>
> --> Segundo a documentacão do Postgresql em:
> http://pgdocptbr.sourceforge.net/pg80/performance-tips.html
>
> "o valor de "loops" (laços) expressa o número total de execuções do nó, e os
> valores de "actual time" (tempo real) e "rows" (linhas) mostrados são
> valores médios por execução Deve ser multiplicado pelo valor de "loops"
> para obter o tempo total realmente gasto no nó."
>
> Mas veja esse caso, em que o tempo total da query foi de 66 minutos.
> ( Explain Analyze completo e Query nesse link: https://goo.gl/Kp45fu  ou
> anexo )
>
> O que me interessa é este trecho:
>
> #
>->  Index Scan using idx_l_partkeylineitem000x on lineitem
> (cost=0.57..97.65 rows=26 width=36)
>   (actual time=23.615..419.113 rows=30 loops=26469)
>   Index Cond: (l_partkey = part.p_partkey)
> #
> Segundo a documentacão, deveria-se multiplicar o Actual Time pelo número de
> Loops.
> Ou seja:   419113 ms --> 419113/1000/60 =  6.9 minutos  * 26469 (loops) =
> 182,6 minutos.
>
> Mas como esse trecho demora 182,6 minutos, se a query inteira executou em 66
> minutos?
>
> Claro que estou cometendo algum erro de cálculo, mas se alguém puder me dar
> uma dica de como faria esse cálculo de tempo.
> O que preciso é saber qual o tempo gasto para percorrer o índice
> idx_l_partkeylineitem000x, lembrando que fiz um Explain Analyze que
> teoricamente é o tempo real gasto e não uma estimativa como no Explain.
>
> []'s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Cálculo de tempo em Exp Analyze

[Neto pr]

Saudacões,
Estou tentando interpretar um Explain Analyze, mas travei nisso:

--> Segundo a documentacão do Postgresql em:
http://pgdocptbr.sourceforge.net/pg80/performance-tips.html

"o valor de "loops" (laços) expressa o número total de execuções do nó, e
os valores de "actual time" (tempo real) e "rows" (linhas) mostrados são
valores médios por execução Deve ser multiplicado pelo valor de "loops"
para obter o tempo total realmente gasto no nó."

Mas veja esse caso, em que o tempo total da query foi de 66 minutos.
( Explain Analyze completo e Query nesse link: https://goo.gl/Kp45fu  ou
anexo )

O que me interessa é este trecho:

#
   ->  Index Scan using idx_l_partkeylineitem000x on lineitem
 (cost=0.57..97.65 rows=26 width=36)
  (actual time=23.615..419.113 rows=30 loops=26469)

  Index Cond: (l_partkey = part.p_partkey)

#

Segundo a documentacão, deveria-se multiplicar o Actual Time pelo número de
Loops.
Ou seja:   419113 ms --> 419113/1000/60 =  6.9 minutos  * 26469 (loops) =
182,6 minutos.

Mas como esse trecho demora 182,6 minutos, se a query inteira executou em
66 minutos?

Claro que estou cometendo algum erro de cálculo, mas se alguém puder me dar
uma dica de como faria esse cálculo de tempo.
O que preciso é saber qual o tempo gasto para percorrer o índice
idx_l_partkeylineitem000x, lembrando que fiz um Explain Analyze que
teoricamente é o tempo real gasto e não uma estimativa como no Explain.

[]'s Neto
 Finalize GroupAggregate  (cost=2360092.54..2361201.87 rows=2406 width=40)
 (actual time=4011611.760..4011611.772 rows=2 loops=1)  Group Key: 
(date_part(_year_::text,  (orders.o_orderdate)::timestamp without time zone))  
Buffers: shared 
hit=468227 read=495151, temp read=45083 written=45001
   ->  Gather Merge  (cost=2360092.54..2361087.59 rows=4812 width=72) (actual 
time=4011601.629..4011611.739 rows=6 loops=1)   
Workers Planned: 2Workers Launched: 2Buffers: shared 
hit=468227 
read=495151, temp read=45083 written=45001
->  Partial GroupAggregate   (cost=2359092.52..2359532.14 rows=2406 
width=72) (actual time=4011126.201..4011136.382 rows=2 loops=3)   
Group Key: (date_part(_year_::text, (orders.o_orderdate)::timestamp 
without time zone))
Buffers: shared hit=1395591 read=1498268 written=3, temp read=135274 
written=135028
  ->  Sort  (cost=2359092.52..2359136.02 rows=17400 width=46) 
(actual time=405.986..407.657 rows=16138 loops=3)
  Sort Key: (date_part(_year_::text, 
(orders.o_orderdate)::timestamp without time zone)) 
 Sort Method: quicksort  Memory: 1631kB
 Buffers: shared hit=1395591 read=1498268 written=3, temp 
read=135274 written=135028
 -> Hash Join  (cost=1200128.12..2357866.97 rows=17400 
width=46) (actual time=140888.039..4011107.564 rows=16138 loops=3)  

 Hash Cond: (supplier.s_nationkey = n2.n_nationkey) 
 
 Buffers: shared hit=1395578 read=1498267 written=3, temp 
read=135274 written=135028  
 ->  Hash Join  (cost=1200126.56..2357564.91 rows=17400 
width=24) (actual time=140887.677..4011095.102 rows=16138 loops=3)  
  
 Hash Cond: (lineitem.l_suppkey = supplier.s_suppkey)  
  Buffers: shared hit=1395544 read=1498264 
written=3, temp read=135274 written=135028
  ->  Hash Join  (cost=1190051.56..2346086.71 
rows=17441 width=24) (actual time=87857.582..4006208.057 rows=16138 loops=3)
  
  Hash Cond: (lineitem.l_orderkey = 
orders.o_orderkey)  
  Buffers: shared hit=1386717 read=1493249 
written=3, temp read=133058 written=132830  
  ->  Nested Loop  (cost=747.67..1144119.43 
rows=285995 width=28) (actual time=42.010..3730700.624 rows=264822 loops=3) 
   
  Buffers: shared hit=84397 read=841016 
   
  ->  Parallel Bitmap Heap Scan on part  
(cost=747.10..56230.60 rows=1 width=4) (actual time=36.759..32068.811 
rows=8823 loops=3)
  Recheck Cond: ((p_type)::text = _LARGE BRUSHED 
NICKEL_::text) 
  Heap Blocks: exact=7554   
   
  Buffers:shared 

[pgbr-geral] Explain analyze buffers

[Neto pr]

Pessoal,
Neste Explain Analyse, Buffers abaixo, tem a presenca de 2 indices
secundários btree que criei.
Estou querendo migrar eles para um SSD para ver se tem melhor
performance. Veja a característica deles

* Indice idx_l_partkeylineitem000  tem 2,5 Gb
* Indice idx_p_typepart000  tem 157 Mb

Gostaria de saber o que significa o Rows abaixo, seria o numero linhas
que foram obtidas da tabela através do índice?
---> Bitmap Index Scan on idx_p_typepart000  (cost=0.00..740.43
rows=26667 width=0)
---> Index Scan using idx_l_partkeylineitem000 on lineitem
(cost=0.57..97.65 rows=26 width=36) (actual time=46.953..503.126
rows=30 loops=26469)

Pois se analisar o indice idx_p_typepart000 apesar de ser menor, foi
bem mais utilizado (26667 rows)  que o outro.

Sobre o que foi encontrado no Buffer, alguém saberia infomar o que seria:
---> Buffers: shared hit=1394261 read=1499550 written=2, temp
read=135262 written=135016
Seria o que foi lido, escrito no buffer?  mas está em que medida (kb,
bytes, mb??)
O que seria o Hit?

-EXPLAIN ANALYSE
BUFFERS-
Finalize GroupAggregate  (cost=2360092.54..2361201.87 rows=2406
width=40) (actual time=4636719.848..4636719.861 rows=2 loops=1)
  Group Key: (date_part(_year_::text, (orders.o_orderdate)::timestamp
without time zone))
  Buffers: shared hit=448727 read=515529 written=1, temp read=45083
written=45001
  ->  Gather Merge  (cost=2360092.54..2361087.59 rows=4812 width=72)
(actual time=4636709.744..4636719.825 rows=6 loops=1)
Workers Planned: 2Workers Launched: 2Buffers:
shared hit=448727 read=515529 written=1, temp read=45083 written=45001
->  Partial GroupAggregate  (cost=2359092.52..2359532.14
rows=2406 width=72) (actual time=4636362.931..4636373.148 rows=2
loops=3)
  Group Key: (date_part(_year_::text,
(orders.o_orderdate)::timestamp without time zone))
  Buffers: shared hit=1394318 read=1499550 written=2, temp
read=135262 written=135016
  ->  Sort  (cost=2359092.52..2359136.02 rows=17400
width=46) (actual time=4636352.717..4636354.392 rows=16138 loops=3)
Sort Key: (date_part(_year_::text,
(orders.o_orderdate)::timestamp without time zone))
Sort Method: quicksort  Memory: 1641kB
Buffers: shared hit=1394318 read=1499550
written=2, temp read=135262 written=135016
->  Hash Join  (cost=1200128.12..2357866.97
rows=17400 width=46) (actual time=151052.112..4636336.400 rows=16138
loops=3)
  Hash Cond: (supplier.s_nationkey = n2.n_nationkey)
, Buffers: shared hit=1394304 read=1499550
written=2, temp read=135262 written=135016
  ->  Hash Join  (cost=1200126.56..2357564.91
rows=17400 width=24) (actual time=151052.004..4636323.494 rows=16138
loops=3)
Hash Cond: (lineitem.l_suppkey =
supplier.s_suppkey)
Buffers: shared hit=1394261
read=1499550 written=2, temp read=135262 written=135016
->  Hash Join
(cost=1190051.56..2346086.71 rows=17441 width=24) (actual
time=86075.147..4624489.804 rows=16138 loops=3)
  Hash Cond: (lineitem.l_orderkey
= orders.o_orderkey)
  Buffers: shared hit=1386918
read=1493051 written=2, temp read=133048 written=132820
  ->  Nested Loop
(cost=747.67..1144119.43 rows=285995 width=28) (actual
time=90.131..4473100.641 rows=264822 loops=3)
Buffers: shared hit=84395
read=841021
->  Parallel Bitmap Heap
Scan on part  (cost=747.10..56230.60 rows=1 width=4) (actual
time=48.979..32834.581 rows=8823 loops=3)
  Recheck Cond:
((p_type)::text = _LARGE BRUSHED NICKEL_::text)
  Heap Blocks: exact=7547
  Buffers: shared read=22871
  ->  Bitmap Index
Scan on idx_p_typepart000  (cost=0.00..740.43 rows=26667 width=0)
(actual time=31.036..31.036 rows=26469 loops=1)
Index Cond:
((p_type)::text = _LARGE BRUSHED NICKEL_::text)
Buffers: shared read=134
->  Index Scan using
idx_l_partkeylineitem000 on lineitem  (cost=0.57..97.65 rows=26
width=36) (actual time=46.953..503.126 rows=30 loops=26469)
---
- QUERY No 8

[pgbr-geral] Ajuda parâmetro work_mem

[Neto pr]

Pessoal

Já li em alguns foruns como abaixo, que alterar o Shared_Buffer para
deixar mais memória RAM disponível p/ o SGBD as vezes acaba por
diminuir o desempenho:

https://www.postgresql.org/message-id/CACezXZ_w7HbqSxZ=5SJH=kxb4nbdnbpdejttsau6ec1aeo4...@mail.gmail.com

Mas e no caso do Work_Mem, responsável por limitar a quantidade de
memória RAM para o operacões de classificacão e ordenacão para uma
única operacão, será que teria algum efeito colateral em alterar isso,
para uma quantidade maior?

Estou fazendo testes com o benchmark TPCH e quase todas as consultas
tem group e order by.
https://www.maxwell.vrac.puc-rio.br/acessoConteudo.php?nrseqoco=42150
(pagina 37)

Peguei duas indicacões pelas ferramentas abaixo, no meu caso estou com
um Servidor dedicado e com poucas conexões sendo utilizadas, no máximo
10, e vejam o que foi me indicado:

- pgtune = 104 MB (para 10 conexões no máximo).
- pgconfig.org = 410 MB (para 10 conexões no máximo)

Alguma opinião se a alteracão desse parametro, traria algum efeito
maléfico no desempenho?
Que valores utilizam x conexões?

Os outros parametros eu utilizo o padrão, a versão do postgresql  é a
10b3, Proc Xeon 2.8GHz/4-core- 8gb Ram, SO Debian 8.

[ ]'s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Índices em SSD

[Neto pr]

Em 5 de setembro de 2017 17:59, Sebastian Webber
<sebast...@swebber.me> escreveu:
>
>
> Em ter, 5 de set de 2017 às 17:26, Neto pr <neto...@gmail.com> escreveu:
>>
>> Olá pessoal!
>>
>> Estou utilizando atualmente postgresql 10,Proc Xeon 2.8GHz/4-core-
>> 8gb Ram, SO Debian 8.
>
>
> Rodando a beta em produção? ou apenas testes de benchmark?
>
Apenas Benchmark, estou utilizando aquele TPC-H 40GB, estou em um
trabalho de pesquisa em performance de SGBD.

>>
>> Estou planejando migrar alguns índices de um disco Sata 7200 rpm, para
>> um SSD, devido a maior velocidade de leitura desses discos.
>> Infelizmente as tabelas não podem ser migradas, pois não haveria
>> espaco no SSD para tanto.
>
>
> Isso seria uma coisa interessante, assim como usar o ssd como cache desse
> disco sata 7.2k rpm.
>

Interessante a alternativa de usar SSD para cache, mas no momento
estou focado somente em testar a estrategia de migrar os indices, mas
futuramente pretendo testar essa alternativa.

> Isso é relativamente fácil de fazer com zfs, dá uma olhada[1].
>
>
>>
>> Inicialmente estava pensando em migrar somente os índices que seriam
>> maiores  que o SHARED_BUFFER do meu servidor, pois acredito que
>> indices menores que o SHARED_BUFFER não valeria a pena.
>
>
> Tem um grande depende aqui: seria ideal ter memória o bastante pra isso,
> pelo menos pra cachear esses datafiles antes de bater no disco. Classo que
> isso não iria impedir de ler o disco, mas ia fazer diferença depois que os
> dados estão no cache.

Não entendi muito bem, pois o que voce ira cachear depende do tamanho
do shared_buffer configurado certo? O que li sobre o Shared_Buffer é
que ele é o parametro relacionado a memória compartilhada , que
controla o tamanho do bloco em memória destinado ao armazenamento de
dados a serem gravados ou já lidos pelo SGBD.
Eu estou utilizando o valor padrão de 128 mb para Shared_Buffer, pois
alterei para 2 GB baseado na recomendacão da ferramenta pgconfi.org
mas ai ocorreu que os indices pararam de ser utilizados pelo SGBD.
Desta forma, resolvi voltar ao valor padrao.

>>
>>
>> Alguem já utilizou essa estratégia de deixar a tabela em um tipo de
>> disco (por exemplo Hdd)  e indices em outro (SSD por exemplo)?
>
>
> Já utilizei raids diferentes e tive um desempenho interessante.

Voce utilizou com discos SAS 15K rpm? ou SSD?
>
>>
>> Será que reduziria o tempo de execucao das queries?
>
>
> Honestamente, depende das consultas que rodam no banco. Conta mais detalhes
> do teu ambiente e ap e quais tipos de consultas são mais frequentes. Com
> isso da pra ser mais acertivo.
>>

As consultas e especificacão das tabelas estão nesse link abaixo:

https://www.maxwell.vrac.puc-rio.br/acessoConteudo.php?nrseqoco=42150
 (pagina 35)

>>
>> O ambiente de execucão é um Data warehouse, e a maioria dos SQLs sao
>> consultas, quase nada de atualizacões.
>
>
> Massa e quais parametros vc ajustou no postgresql.conf?

Estou utilizando o padrão, conforme expliquei o motivo acima

Precisa saber se o tamanho do indice versus shared_buffer seria um bom
parametro,  ou  mesmo a relacao do tamanho indice x tamanho memoria
seria melhor..


>>
>>
>> Saudacões
>
>
>
> []'s
>
> http://evol-monkey.blogspot.com.br/2017/08/postgresql-on-zfs.html
>
>
> ___
> 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] Índices em SSD

[Neto pr]

Olá pessoal!

Estou utilizando atualmente postgresql 10,Proc Xeon 2.8GHz/4-core-
8gb Ram, SO Debian 8.
Estou planejando migrar alguns índices de um disco Sata 7200 rpm, para
um SSD, devido a maior velocidade de leitura desses discos.
Infelizmente as tabelas não podem ser migradas, pois não haveria
espaco no SSD para tanto.
Inicialmente estava pensando em migrar somente os índices que seriam
maiores  que o SHARED_BUFFER do meu servidor, pois acredito que
indices menores que o SHARED_BUFFER não valeria a pena.

Alguem já utilizou essa estratégia de deixar a tabela em um tipo de
disco (por exemplo Hdd)  e indices em outro (SSD por exemplo)?

Será que reduziria o tempo de execucao das queries?

O ambiente de execucão é um Data warehouse, e a maioria dos SQLs sao
consultas, quase nada de atualizacões.

Saudacões

[ ]'s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ferramenta auxilio p/ postgresql.conf

[Neto pr]

Em 25 de agosto de 2017 15:54, Euler Taveira <eu...@timbira.com.br> escreveu:
> Em 25 de agosto de 2017 15:07, Neto pr <neto...@gmail.com> escreveu:
>> Pessoal
>> alguém sabe alguma ferramenta que auxilia no ajuste dos parâmetros do
>> arquivo postgresql.conf.
>>
> Ao invés de ficar procurando ferramenta que apenas sugere valores
> empiricamente, aconselho que você leia a documentação e/ou código
> fonte para entender qual a influência de cada parâmetro na performance
> do Postgres.
>
>> Já fiz uso do PGTUNE [1] e do Pgconfi [2], mas eles nao indicam nada
>> dos parâmetros:
>>
>> - cpu_tuple_cost
>> - cpu_index_tuple_cost
>> - cpu_operator_cost
>> - seq_page_cost
>> - random_page_cost
>>
> Eu não aconselho mexer nesses parâmetros a não ser que você saiba
> exatamente o que está fazendo. A alteração desses parâmetros podem
> piorar a escolha de planos de execução. Para mexer nesses parâmetros
> você precisa conhecer como o otimizador os utiliza para fazer a
> mudança correta.
>
>> Eu estou com o problema relatado no outro email, em que o otimizador
>> está sempre escolhendo fazer full-scan ao inves de estrategias
>> indexada por exemplo.
>>
> Não abra outra discussão se o assunto é o mesmo. Consultas do TCP-H
> geralmente demandam mais hardware para serem processadas pois
> processam uma "massa" de dados. Não espere que as consultas do
> referido teste rodem com rapidez em um hardware modesto; não
> executarão.
>
> Você já tentou ativar o paralelismo para melhorar o tempo de execução
> da consulta? Eu aconselho fortemente testar a versão 10 (que incluiu
> suporte a paralelismo do Merge Join, Bitmap Heap Scan, dentre outros).
>
>
Sobre o Paralelismo eu não tinha ativado.
Mas a alguns dias atrás instalei a versao 10 beta3 e fiquei satisfeito
com os testes utilizando a escala de 40 GB do Benchmark TPC-H.
Mas utilizei um servidor com 8gb de RAM com disco SSD.

Pergunta:
Para maximizar a utilizacão de paralelismo basta ativar o parametro
force_parallel_mode = on ?

Outra questão, todos os parametros presentes no postgresql.conf sao
globais ou seja, valem para todos os usuários, ou tem algum que pode
ser configurado por sessão de usuário.

Vi que tem no postgresql.conf os parametros:

#max_parallel_workers_per_gather = 2# taken from max_parallel_workers
#max_parallel_workers = 8   # maximum number of
max_worker_processes that can be used in parallel queries

Gostaria de saber se daria para configurar paralelismo por sessão de
usuário, lembro que no Oracle é feito utilizando hints na query ...
claro que cada sgbd tem sua forma particular de operar.

Ainda sobre o postgresql.conf, para ativar as alteracões é necessario
sempre reinicar o SGBD após salvar?

Vi que tem como fazer um update em pg_settings, mas gostaria de saber
se precisaria reiniciar o sgbd para efetivar a alteracão.

-- UPDATE pg_settings SET parametro = 'configuration_valor';

Qualquer dica, nem que seja parcial sobre as questões são bem vindas.

[ ]'s Neto


> --
>Euler Taveira   Timbira -
> http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> 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] Ferramenta auxilio p/ postgresql.conf

[Neto pr]

Pessoal
alguém sabe alguma ferramenta que auxilia no ajuste dos parâmetros do
arquivo postgresql.conf.

Já fiz uso do PGTUNE [1] e do Pgconfi [2], mas eles nao indicam nada
dos parâmetros:

- cpu_tuple_cost
- cpu_index_tuple_cost
- cpu_operator_cost
- seq_page_cost
- random_page_cost

Eu estou com o problema relatado no outro email, em que o otimizador
está sempre escolhendo fazer full-scan ao inves de estrategias
indexada por exemplo.
Entendo que as vezes realmente é mais ágil fazer full-scan do que sair
percorrendo um índice, que exige acesso aleatório, mas testei também
com discos SSDs , alterando random_page_cost = 1, e continuou
acontecendo o problema (custo incorretos) e  estrategias indexadas,
serem menos eficientes que sem indices. Penso que devo ajustar esses
parametros melhor. Se tiverem alguma dica de ferramenta ou outra
forma, por favor retornem.

[1]: pgtune.leopard.in.ua
[2]: www.pgconfig.org

[]`s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Análise de Plano de Execução

[Neto pr]

Em 25 de agosto de 2017 10:23, Flavio Henrique Araque Gurgel
 escreveu:
>> > Se você muda essas configurações e o servidor não acompanha, seus custos
>> > mudam nas estatísticas e o PostgreSQL vai traçar planos diferentes,
>> > baseados
>> > no que você configurou, mas suas configurações podem não ser ótimas e o
>> > desempenho será pior.
>>
>> Talvez isso que esta ocorrendo, pois esse servidor veio com 8 gb de
>> memoria, para ver se ele utilizava os indices, reduzi a memoria RAM
>> para 4 GB (de  8gb que ele tinha), para ver se ao inves de buscar no
>> disco e jogar para memoria RAM se ele iria usar os indices e ter um
>> resultado melhor, pelo fato de nao ter espaco em memoria RAM,  mas
>> mesmo com apenas 4 gb de RAM, o desempenho utilizando indices 'e
>> deploravel. .
>>
>> []`s Neto
>
>
> Vejo que você tem apenas um grande disco SATA de 7200 rpm. Isso é...
> muito... lento... pra qualquer coisa aleatória.
>
> Num disco rotativo, quanto maior o disco unitário, pior. Prefere-se ter 4
> discos de 500 GB e 15000 rpm em RAID 10 sobre um único disco de 1TB e 7200
> rpm por isso, o desempenho é, n mínimo, 4x maior para leituras aleatórias
>

Entao, sobre os discos, voce esta querendo dizer que utilizando
indices que usa muito acesso aleatorio, eu nao conseguiria obter bons
resultados com esse disco?

> Pode ser que você tenha de aumentar random_page_cost para algo ainda maior
> que 4 com esse disco. Sugiro testá-lo com a ferramenta bonnie++ também.

Entao, eu tambem tinha pensado nisso, e coloquei um SSD de 500 GB (
este aqui 
http://www.samsung.com/semiconductor/minisite/ssd/product/consumer/850evo.html),
mas para minha surpresa, o desempenho utilizando indices foi similar
as consultas sem indices, mesmo alterando o valor de #random_page_cost
 para 1.0, pois o custo de acesso sequencial e aleatorio em SSD sao
bem proximos.
Entao sera que no caso do uso de SSD, os parametros de CPU
(cpu_index_tuple_cost entre outros) sera que foram o causador do
desempenho ruim utilizando indices?

Veja abaixo o que coletei de resultados com disco SSDs, tempo pior e
custos incorretos (menores):

Indices |Query|Tempo_Gasto   |Custo_Total

Sim  10   00:07:04 40743017.17
Nao  10   00:02:14 41341406.62
Sim  15   00:10:03  6431359.90
Nao  15  00:01:56 9608659.87
Sim  20   00:12:48 8412159.69
Nao  20  00:05:49  9537835.93
=

[]`s Neto

>
> []s
> Flavio Gurgel
>
> ___
> 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

Re: [pgbr-geral] Análise de Plano de Execução

[Neto pr]

Em 25 de agosto de 2017 10:22, Euler Taveira <eu...@timbira.com.br> escreveu:
> Em 25 de agosto de 2017 09:51, Neto pr <neto...@gmail.com> escreveu:
>> Talvez isso que esta ocorrendo, pois esse servidor veio com 8 gb de
>> memoria, para ver se ele utilizava os indices, reduzi a memoria RAM
>> para 4 GB (de  8gb que ele tinha), para ver se ao inves de buscar no
>> disco e jogar para memoria RAM se ele iria usar os indices e ter um
>> resultado melhor, pelo fato de nao ter espaco em memoria RAM,  mas
>> mesmo com apenas 4 gb de RAM, o desempenho utilizando indices 'e
>> deploravel. .
>>
> Você executou essa consulta quantas vezes para concluir que o
> desempenho é deplorável? Se você observar, o passo mais lento da
> consulta (Bitmap Heap Scan) depende muito da velocidade de leitura do
> disco e/ou cache do SO.
>
Ola Euler,
eu testei algumas (5 vezes) a consulta para concluir isto.
Mas estava utilizando outra estrategia.
Como o benchmark tem 22 consultas, pensei em isolar cada consulta,
para que o resultado em cache de outra consulta nao interferir na
consulta corrente.
Entao apago o cache antes do Explain Analyze de cada consulta executada:

/etc/init.d/pgsql stop
sync
echo "apagar cache !!"
echo 3 > /proc/sys/vm/drop_caches
/etc/init.d/pgsql start

> Fazer consulta "a frio" (iniciar o serviço e fazer a consulta uma vez)
> não é uma boa prática para medir tempo de consulta. O ideal é que você
> faça um aquecimento (warmup) antes de fazer a coleta do plano. Além
> disso, executar um ANALYZE em todas as tabelas envolvidas antes do
> teste é algo essencial.

Ok, vou testar essa estrategia de "warmup" antes de fazer a coleta do
plano, para verificar se os resultados com indices melhoram.
Sobre o ANALYZE faco isso antes de executar as consultas sim.


>
>
> --
>Euler Taveira   Timbira -
> http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> 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

Re: [pgbr-geral] Análise de Plano de Execução

[Neto pr]

Em 25 de agosto de 2017 05:53, Flavio Henrique Araque Gurgel
<fha...@gmail.com> escreveu:
>
>
> Em sex, 25 de ago de 2017 às 10:45, Neto pr <neto...@gmail.com> escreveu:
>>
>> Olá Pessoal
>> Preciso de uma ajuda na análise desses 2 planos de execução.
>> Gostaria de descobrir, porque uma query sem índice executa mais rápido
>> (7 vezes+-) do que com índice, embora os custos sejam menores.
>> Tenho outros casos que aconteceram a mesma situação.  Ajustei o
>> servidor conforme www.pgconfig.org.
>> Estou utilizando o postgresql  versão  9.0.1 no SO Debian 8, sei que é
>> uma versão antiga, mas fiz o teste em uma versão 9.6.4 e também
>> ocorreu o mesmo.
>>
>> Pelo que vi está utilizando o índice  shipmodelineitem000 no 1º plano...
>>
>> Query| Índices(sim/não)  |Tempo gasto|Total Cost
>> =
>> 12   com índice  00:08:58  2710805.51
>> 12   sem índice  00:01:42   3365996.34
>>
>> - Explain Analyze   Query 12  Utilizando índice
>> 
>> Sort  (cost=2710805.51..2710805.51 rows=1 width=27) (actual
>> time=537713.672..537713.672 rows=2 loops=1)
>>   Sort Key: lineitem.l_shipmode
>> Sort Method:  quicksort  Memory: 25kB
>>   ->  HashAggregate  (cost=2710805.47..2710805.50 rows=1 width=27)
>> (actual time=537713.597..537713.598 rows=2 loops=1)
>>   ->  Merge Join  (cost=1994471.69..2708777.28 rows=270426
>> width=27) (actual time=510717.977..536818.802 rows=311208 loops=1)
>>   Merge Cond: (orders.o_orderkey = lineitem.l_orderkey)
>> ->  Index Scan using orders_pkey on orders
>> (cost=0.00..672772.57 rows=1545 width=20)
>> (actual time=0.019..20898.325 rows=1472
>> loops=1)
>>   ->  Sort  (cost=1994455.40..1995131.47
>> rows=270426 width=19) (actual time=510690.114..510915.678 rows=311208
>> loops=1)
>>  Sort Key: lineitem.l_orderkey
>> Sort Method:  external sort  Disk:
>> 11568kB
>>  ->  Bitmap Heap Scan on
>> lineitem  (cost=336295.10..1970056.39 rows=270426 width=19) (actual
>> time=419620.817..509685.421 rows=311208 loops=1)
>>Recheck Cond:
>> (l_shipmode = ANY (_{TRUCK,AIR}_::bpchar[]))
>> Filter:
>> ((l_commitdate < l_receiptdate) AND (l_shipdate < l_commitdate) AND
>> (l_receiptdate >= _1997-01-01_::date) AND (l_receiptdate <
>> _1998-01-0100:00:00_::timestamp without time zone))
>> ->  Bitmap
>> Index Scan on idx_l_shipmodelineitem000  (cost=0.00..336227.49
>> rows=15942635 width=0) (actual time=419437.172..419437.172
>> rows=17133713 loops=1)
>>   Index
>> Cond: (l_shipmode = ANY (_{TRUCK,AIR}_::bpchar[]))
>>
>> Total runtime: 537728.848 ms
>>
>>
>> -   Explain AnalyzeQuery 12  SEM Utilizar índice
>> 
>> Sort  (cost=3365996.33..3365996.34 rows=1 width=27) (actual
>> time=101850.883..101850.884 rows=2 loops=1)
>>   Sort Key: lineitem.l_shipmode  Sort Method:  quicksort  Memory: 25kB
>> ->  HashAggregate  (cost=3365996.30..3365996.32 rows=1 width=27)
>> (actual time=101850.798..101850.800 rows=2 loops=1)
>> ->  Merge Join  (cost=2649608.28..3363936.68 rows=274616
>> width=27) (actual time=75497.181..100938.830 rows=311208 loops=1)
>>  Merge Cond: (orders.o_orderkey = lineitem.l_orderkey)
>>  ->  Index Scan using orders_pkey on orders
>> (cost=0.00..672771.90 rows=1500 width=20) (actual
>> time=0.020..20272.828 rows=1472 loops=1)
>>   ->  Sort  (cost=2649545.68..2650232.22
>> rows=274616 width=19) (actual time=75364.450..75618.772 rows=311208
>> loops=1)
>> Sort Key: lineitem.l_orderkey
>> Sort Method:  external sort Disk: 11568kB
>>->  Seq Scan on lineitem
>> (cost=0.00..2624738.17 rows=274616 width=19) (actual
>> time=0.839..74391.087 rows=311208 loops=1)
>>  Filter: ((l_shipmode=
>> ANY (_{TRUCK,AIR}_::bp

[pgbr-geral] Análise de Plano de Execução

[Neto pr]

Olá Pessoal
Preciso de uma ajuda na análise desses 2 planos de execução.
Gostaria de descobrir, porque uma query sem índice executa mais rápido
(7 vezes+-) do que com índice, embora os custos sejam menores.
Tenho outros casos que aconteceram a mesma situação.  Ajustei o
servidor conforme www.pgconfig.org.
Estou utilizando o postgresql  versão  9.0.1 no SO Debian 8, sei que é
uma versão antiga, mas fiz o teste em uma versão 9.6.4 e também
ocorreu o mesmo.

Pelo que vi está utilizando o índice  shipmodelineitem000 no 1º plano...

Query| Índices(sim/não)  |Tempo gasto|Total Cost
=
12   com índice  00:08:58  2710805.51
12   sem índice  00:01:42   3365996.34

- Explain Analyze   Query 12  Utilizando índice

Sort  (cost=2710805.51..2710805.51 rows=1 width=27) (actual
time=537713.672..537713.672 rows=2 loops=1)
  Sort Key: lineitem.l_shipmode
Sort Method:  quicksort  Memory: 25kB
  ->  HashAggregate  (cost=2710805.47..2710805.50 rows=1 width=27)
(actual time=537713.597..537713.598 rows=2 loops=1)
  ->  Merge Join  (cost=1994471.69..2708777.28 rows=270426
width=27) (actual time=510717.977..536818.802 rows=311208 loops=1)
  Merge Cond: (orders.o_orderkey = lineitem.l_orderkey)
->  Index Scan using orders_pkey on orders
(cost=0.00..672772.57 rows=1545 width=20)
(actual time=0.019..20898.325 rows=1472 loops=1)
  ->  Sort  (cost=1994455.40..1995131.47
rows=270426 width=19) (actual time=510690.114..510915.678 rows=311208
loops=1)
 Sort Key: lineitem.l_orderkey
Sort Method:  external sort  Disk: 11568kB
 ->  Bitmap Heap Scan on
lineitem  (cost=336295.10..1970056.39 rows=270426 width=19) (actual
time=419620.817..509685.421 rows=311208 loops=1)
   Recheck Cond:
(l_shipmode = ANY (_{TRUCK,AIR}_::bpchar[]))
Filter:
((l_commitdate < l_receiptdate) AND (l_shipdate < l_commitdate) AND
(l_receiptdate >= _1997-01-01_::date) AND (l_receiptdate <
_1998-01-0100:00:00_::timestamp without time zone))
->  Bitmap
Index Scan on idx_l_shipmodelineitem000  (cost=0.00..336227.49
rows=15942635 width=0) (actual time=419437.172..419437.172
rows=17133713 loops=1)
  Index
Cond: (l_shipmode = ANY (_{TRUCK,AIR}_::bpchar[]))

Total runtime: 537728.848 ms


-   Explain AnalyzeQuery 12  SEM Utilizar índice

Sort  (cost=3365996.33..3365996.34 rows=1 width=27) (actual
time=101850.883..101850.884 rows=2 loops=1)
  Sort Key: lineitem.l_shipmode  Sort Method:  quicksort  Memory: 25kB
->  HashAggregate  (cost=3365996.30..3365996.32 rows=1 width=27)
(actual time=101850.798..101850.800 rows=2 loops=1)
->  Merge Join  (cost=2649608.28..3363936.68 rows=274616
width=27) (actual time=75497.181..100938.830 rows=311208 loops=1)
 Merge Cond: (orders.o_orderkey = lineitem.l_orderkey)
 ->  Index Scan using orders_pkey on orders
(cost=0.00..672771.90 rows=1500 width=20) (actual
time=0.020..20272.828 rows=1472 loops=1)
  ->  Sort  (cost=2649545.68..2650232.22
rows=274616 width=19) (actual time=75364.450..75618.772 rows=311208
loops=1)
Sort Key: lineitem.l_orderkey
Sort Method:  external sort Disk: 11568kB
   ->  Seq Scan on lineitem
(cost=0.00..2624738.17 rows=274616 width=19) (actual
time=0.839..74391.087 rows=311208 loops=1)
 Filter: ((l_shipmode=
ANY (_{TRUCK,AIR}_::bpchar[])) AND (l_commitdate < l_receiptdate) AND
(l_shipdate < l_commitdate) AND (l_receiptdate >= _1997-01-01_::date)
AND (l_receiptdate < _1998-01-01 00:00:00_::timestamp without time
zone))

Total runtime: 101865.253 ms

 --- query 12 --
  select
l_shipmode,
sum(case
when o_orderpriority = '1-URGENT'
or o_orderpriority = '2-HIGH'
then 1
else 0
end) as high_line_count,
sum(case
when o_orderpriority <> '1-URGENT'
and o_orderpriority <> '2-HIGH'
then 1
else 0
end) as low_line_count
from
orders,
lineitem
where
o_orderkey = l_orderkey
and l_shipmode in ('TRUCK', 'AIR')
and l_commitdate < l_receiptdate
and l_shipdate < l_commitdate
and l_receiptdate >= date '1997-01-01'
and l_receiptdate < date '1997-01-01' + interval '1' year
group by
l_shipmode
order by
l_shipmode

[]`s Neto

[pgbr-geral] Explain - Custo x Tempo dessintonizados?

[Neto pr]

Alguém poderia me ajudar a interpretar o porque desta situação.

Estou fazendo um experimento com 22 queries do Benchmark TPCH[1],
verificando o desempenho de índices nas consultas.

Das 22 queries, em 5 delas o otimizador utilizou índices secundários,
definidos em algumas colunas das 8 tabelas do BD.
Em outro experimento em paralelo executei essas 5 queries num BD sem
uso de índices, exatamente para ver se o uso de índices resultava em
diminuição de tempo, mas aconteceu o contrário, ou seja,com índice
aumentou o tempo das consultas.

Gostaria de entender, porque a estatística de custo errou em todos os
casos, ou seja, embora o custo_total nas queries que utilizaram
índices são menores, o tempo gasto para executar foi maior que as
queries que não utilizaram indices.
Vejam abaixo, que a primeira linha refere-se a query 6 que utilizou
índice, o custo foi 3335809, menor do que o custo 5255959, da mesma
query 6 que não utilizou índice. Mas veja o tempo das duas, a query
que utilizou índice demorou 7 minutos enquanto sem o uso de índices
demorou 55 segundos, idem para os demais casos.
Porque será que o custo total mostra o valor menor para todos os
casos? Sendo que demorou mais para executar, o que da a impressão que
o custo foi maior.

Indices |Query |Tempo_Gasto |Custo_Total

Sim   6   00:07:56 3335809.61
Nao   6   00:00:55 5255959.00
Sim   7   00:09:16  5847359.97
Nao  700:02:08 6793148.45
Sim 10   00:07:04 40743017.17
Nao 10   00:02:14 41341406.62
Sim 15   00:10:03  6431359.90
Nao 15  00:01:56 9608659.87
Sim 20   00:12:48 8412159.69
Nao 20  00:05:49  9537835.93
=

Segue a query 6 e o seu Explain Analyse com e sem índices.
- QUERY 6 -
select
sum(l_extendedprice * l_discount) as revenue
from
lineitem
where
l_shipdate >= date '1995-01-01'
and l_shipdate < date '1995-01-01' + interval '1' year
and l_discount between 0.09 - 0.01 and 0.09 + 0.01
and l_quantity < 24;

-- COM ÍNDICE (idx_l_shipdatelineitem000
)--
Plano Execucao:Aggregate  (cost=3335809.59..3335809.61 rows=1
width=16) (actual time=476033.847..476033.847 rows=1 loops=1)
 ->  Bitmap Heap Scan on lineitem  (cost=376416.20..3330284.29
rows=2210122 width=16) (actual time=375293.183..471695.391
rows=2282333 loops=1)
   Recheck Cond: ((l_shipdate >= _1995-01-01_::date) AND
(l_shipdate < _1996-01-01 00:00:00_::timestamp without time zone))
Filter: ((l_discount >= 0.08) AND (l_discount <= 0.10) AND
(l_quantity < 24::numeric))
->  Bitmap Index Scan on idx_l_shipdatelineitem000
(cost=0.00..375863.67 rows=17925026 width=0) (actual
time=375289.456..375289.456 rows=18211743 loops=1)
  Index Cond: ((l_shipdate >= _1995-01-01_::date) AND
(l_shipdate < _1996-01-01 00:00:00_::timestamp without time
zone))Total runtime: 476034.306 ms


-- SEM USO DE ÍNDICE
---
Plano Execucao:Aggregate  (cost=5255958.99..5255959.00 rows=1
width=16) (actual time=55051.051..55051.051 rows=1 loops=1)
  ->  Seq Scan on lineitem  (cost=0.00..5250433.68 rows=2210122
width=16) (actual time=0.394..52236.276 rows=2282333 loops=1)
Filter: ((l_shipdate >= _1995-01-01_::date) AND (l_shipdate <
_1996-01-01 00:00:00_::timestamp without time zone)
AND (l_discount >= 0.08) AND (l_discount <= 0.10) AND
(l_quantity < 24::numeric))Total runtime: 55051.380 ms

Qualquer dica é bem vinda!!
[]`s Neto

[1] www.tpc.org/tpch/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Chave estrangeira x índice

[Neto pr]

Olá pessoal
Agradeço Cleiton e Euler pelas explicações, tanto do tipos de dados
que devem ser iguais nas chaves pk e fk, tanto de que o postgresql
permite criar vários indices sobre a mesma coluna.
Concordo que não criar índice para cada fk ajuda muito, pois com
certeza diminuirá o overhead nas atualizações.

[]`s
Neto
  

  https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Livre de vírus. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avast.com.  




Em 20 de agosto de 2017 11:09, Euler Taveira <eu...@timbira.com.br> escreveu:
> Em 19 de agosto de 2017 18:24, Neto pr <neto...@gmail.com> escreveu:
>> Segundo alguns autores, ao se criar uma chave primaria, na verdade o
>> SGBD cria um índice primário/único no caso de chave primaria. Mas e no
>> caso da chave estrangeira, o SGBD indexa a coluna Fk também?
>>
> Alguns SGBDs criam/criavam índices para cada chave estrangeira criada;
> o PostgreSQL, não. Na minha opinião foi uma decisão sábia do
> PostgreSQL porque (i) nem todo índice de chave estrangeira é utilizado
> (é útil para remover registro que é referenciado por chave estrangeira
> e as tabelas referenciadas são grandes) e (ii) não incha o modelo com
> índices desnecessários.
>
>> Pergunto isso pois criei a seguinte chave estrangeira em um banco de
>> testes (do benchmark TPCH):
>>
>> ALTER TABLE ORDERS ADD FOREIGN KEY (O_CUSTKEY) REFERENCES 
>> CUSTOMER(C_CUSTKEY);
>>
>> Apos tentei criar um índice secundário btree na tabela ORDERS desta forma:
>> CREATE INDEX indice_custkey_customer on ORDERS (O_CUSTKEY);
>>
>> Achei que o PostgreSQL  Não iria permitir isso, pois pensei que a
>> coluna O_CUSTKEY já estava indexada (pela chave estrangeira), mas o
>> PostgreSQL aceitou o índice secundário.
>>
> Como eu disse, o PostgreSQL não cria índice ao criar chave
> estrangeira. Fica a critério do AD/DBA criar tais índices. Além disso,
> você pode criar quantos índices quiser em uma mesma coluna.
>
> euler=# create table foo (a int primary key, b int not null);
> CREATE TABLE
> euler=# create index foo1 on foo(b);
> CREATE INDEX
> euler=# create index foo2 on foo(b);
> CREATE INDEX
> euler=# \d foo
>Tabela "public.foo"
>  Coluna |  Tipo   | Modificadores
> +-+---
>  a  | integer | não nulo
>  b  | integer | não nulo
> Índices:
> "foo_pkey" PRIMARY KEY, btree (a)
> "foo1" btree (b)
> "foo2" btree (b)
>
> Isso é últil para descartar um índice inchado (é claro que essa
> técnica envolve parada. Use CONCURRENTLY para diminuir o tempo de
> bloqueio.).
>
>> Alguém saberia explicar SE ao criar uma chave estrangeira, é criado ou
>> não um índice.
>> Outro dia estava vendo um plano de execução, e no plano tinha o uso de
>> uma chave estrangeira para recuperar registros, por isso também a
>> dúvida.
>>
> O plano pode considerar o uso de índice em uma chave estrangeira (em
> junções o planejador é esperto em utilizar o índice da chave
> primária). Algo como:
>
> SELECT x, y, z FROM orders WHERE o_custkey = 1234;
>
>
> --
>Euler Taveira   Timbira -
> http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> 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] Chave estrangeira x índice

[Neto pr]

Ola pessoal

Sou novo na utilização de PostgreSQL, e tenho a seguinte duvida.

Segundo alguns autores, ao se criar uma chave primaria, na verdade o
SGBD cria um índice primário/único no caso de chave primaria. Mas e no
caso da chave estrangeira, o SGBD indexa a coluna Fk também?

Pergunto isso pois criei a seguinte chave estrangeira em um banco de
testes (do benchmark TPCH):

ALTER TABLE ORDERS ADD FOREIGN KEY (O_CUSTKEY) REFERENCES CUSTOMER(C_CUSTKEY);

Apos tentei criar um índice secundário btree na tabela ORDERS desta forma:
CREATE INDEX indice_custkey_customer on ORDERS (O_CUSTKEY);

Achei que o PostgreSQL  Não iria permitir isso, pois pensei que a
coluna O_CUSTKEY já estava indexada (pela chave estrangeira), mas o
PostgreSQL aceitou o índice secundário.

Alguém saberia explicar SE ao criar uma chave estrangeira, é criado ou
não um índice.
Outro dia estava vendo um plano de execução, e no plano tinha o uso de
uma chave estrangeira para recuperar registros, por isso também a
dúvida.

[]`s Neto
 

  https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Livre de vírus. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avast.com.  



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Reiniciar sequence diariamente

[Neto pr]

Ola pessoal
preciso que uma sequence seja zerada todos os dias, ou seja, que o campo
- start with receba zero.
Estava pensando em criar uma trigger que todos os dias, executa-se um
alter sequence ( ALTER SEQUENCE name_sq  START WITH 0), mas será que
alguem teria uma ideia de outra solução mais rápida.

Eu preciso disso, pois tenho um campo que é a combinação da uma
data+uma sequencia, como todo dia a data muda, nao preciso de uma
sequencia continua. Exemplo:
ids gerados hoje
- 20170527-01
- 20170527-02
- 20170527-03
---
ids gerados amanhã
- 20170527-01
- 20170528-02
- 20170529-03
- 20170529-04

[ ]`s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Índices em Funções

[Neto pr]

Pessoal, talvez a query de exemplo da mensagem anterior, nao foi um
bom exemplo, pois utiliza somente 1 tabela.
Mas tenho muitas outras queries, que envolvem muitas tabelas, com 3
tabelas realmente grandes: lineitem, Orders e partsupp.
Da para ver que os predicados sao bem restritivos, e segundo regras
basicas de tuning, se voce tem predicados restritivos (retorno entre 5
-10%) ai compensaria utilizar indices.

Bom o que acham, olhando a primeira query, aquele select interno "
Select min(ps_supplycost)" veja que o select e' somente em 1 campo, e
o FROM seria em 4 tabelas, neste caso um indice para pegar o valor
minimo, seria uma boa aposta, o que acham?
E na query 2, o campo l_extendedprice e l_discount, sera que um indice
para calculo do  em cada ou multiplo ali, traria beneficio, pensando
que o predicado (where) seria bem restritivo?

Essas queries sao de um benchmark que estou usando (http://www.tpc.org/tpch).

--
select
s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment
from
part, supplier, partsupp, nation, region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and p_size = 25
and p_type like '%STEEL'
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'EUROPE'
and ps_supplycost = (
select
min(ps_supplycost)
from
partsupp, supplier,nation, region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'EUROPE'
)
order by s_acctbal desc, n_name, s_name, p_partkey

-
select
n_name,
sum(l_extendedprice * (1 - l_discount)) as revenue
from
customer, orders, lineitem,supplier, nation, region
where
c_custkey = o_custkey
and l_orderkey = o_orderkey
and l_suppkey = s_suppkey
and c_nationkey = s_nationkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'AMERICA'
and o_orderdate >= date '1995-01-01'
and o_orderdate < date '1995-01-01' + interval '1' year
group by n_name
order by revenue desc

[]`s Neto

2017-04-23 15:05 GMT-03:00 Neto pr <neto...@gmail.com>:
> Pessoal,
>
> Tenho várias consultas como exemplo abaixo, e vou precisar executar em
> bases com 100gb a 500gb do postgreSQL, brevemente.
>
> 
> select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty,
> sum(l_extendedprice) as sum_base_price,
> sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
> sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
> avg(l_quantity) as avg_qty,
> avg(l_extendedprice) as avg_price,
> avg(l_discount) as avg_disc,
> count(*) as count_order
> from lineitem
> where
> l_shipdate <= date '2005-12-01' - interval '117' day
> group by
> l_returnflag,
> l_linestatus
> order by
> l_returnflag,
> l_linestatus;
> --
> Vários autores (cito 3 exemplos abaixo) falam que uma coluna boa
> candidata a índice deve:
> - aparecer na clausula WHERE.
> - aparecer em clausulas de GROUP BY ou ORDER BY
> - etc...
>
> Mas pergunto, e as colunas que aparecem ANTES do WHERE, ou seja no
> SELECT como as colunas com funções  SUM, AVG e COUNT, como acima.
> Pelo que entendi, um índice ajuda a encontar as linhas da tabela mais
> rapidas, e com as linhas encontradas, nao precisaria de um indice para
> fazer SUM, AVG, ou COUNT, seria isso a justificativa para os autores
> não sugerirem criar índices para essas colunas com SUM, AVG e COUNT ?
> e no caso de muitos dados para fazer o SUM, etc?
>
> Mas então porque para o Group By e Order by é sugerido a criação de
> índices, pois na verdade eles fazer de forma similar o que faz o SUM,
> AVG e COUNT, ou seja eles somente manipulam (ordenação/agrupamento) os
> dados e não ajudam a encontrar os mesmo no discos.
>
> Na ref. 3 tem a seguinte afirmação: " Não indexe colunas que aparecem
> em Cláusulas WHERE com funções ou operadores.
> Uma cláusula WHERE que usa uma função, diferente de MIN ou MAX ou um
> operador com uma chave indexada, não é disponibilizado o caminho de
> acesso utilizando o índice, exceto com índices baseados em função."
>
> No entanto ele não fala nada de funcoes ANTES do WHERE. A minha
> questão é compensa criar índices para colunas, se baseando nas colunas
> que aparecem apos o SELECT?
>
> Obs. Eu sei que criar índices demasiadamente causa gargalos em
> atualizações, mas meu ambiente, é mais orientado a 

[pgbr-geral] Índices em Funções

[Neto pr]

Pessoal,

Tenho várias consultas como exemplo abaixo, e vou precisar executar em
bases com 100gb a 500gb do postgreSQL, brevemente.


select l_returnflag, l_linestatus, sum(l_quantity) as sum_qty,
sum(l_extendedprice) as sum_base_price,
sum(l_extendedprice * (1 - l_discount)) as sum_disc_price,
sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge,
avg(l_quantity) as avg_qty,
avg(l_extendedprice) as avg_price,
avg(l_discount) as avg_disc,
count(*) as count_order
from lineitem
where
l_shipdate <= date '2005-12-01' - interval '117' day
group by
l_returnflag,
l_linestatus
order by
l_returnflag,
l_linestatus;
--
Vários autores (cito 3 exemplos abaixo) falam que uma coluna boa
candidata a índice deve:
- aparecer na clausula WHERE.
- aparecer em clausulas de GROUP BY ou ORDER BY
- etc...

Mas pergunto, e as colunas que aparecem ANTES do WHERE, ou seja no
SELECT como as colunas com funções  SUM, AVG e COUNT, como acima.
Pelo que entendi, um índice ajuda a encontar as linhas da tabela mais
rapidas, e com as linhas encontradas, nao precisaria de um indice para
fazer SUM, AVG, ou COUNT, seria isso a justificativa para os autores
não sugerirem criar índices para essas colunas com SUM, AVG e COUNT ?
e no caso de muitos dados para fazer o SUM, etc?

Mas então porque para o Group By e Order by é sugerido a criação de
índices, pois na verdade eles fazer de forma similar o que faz o SUM,
AVG e COUNT, ou seja eles somente manipulam (ordenação/agrupamento) os
dados e não ajudam a encontrar os mesmo no discos.

Na ref. 3 tem a seguinte afirmação: " Não indexe colunas que aparecem
em Cláusulas WHERE com funções ou operadores.
Uma cláusula WHERE que usa uma função, diferente de MIN ou MAX ou um
operador com uma chave indexada, não é disponibilizado o caminho de
acesso utilizando o índice, exceto com índices baseados em função."

No entanto ele não fala nada de funcoes ANTES do WHERE. A minha
questão é compensa criar índices para colunas, se baseando nas colunas
que aparecem apos o SELECT?

Obs. Eu sei que criar índices demasiadamente causa gargalos em
atualizações, mas meu ambiente, é mais orientado a consultas com
poucas atualizações.

1- http://www.cs.toronto.edu/~alan/papers/icde00.pdf (pag 1)
2- Silberchatz, K et. al. Sistemas de banco de dados, Campus, 2006.
3- https://docs.oracle.com/cd/E18283_01/server.112/e16638.pdf (Pag. 371)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] armazenar Plano execução

[Neto pr]

Em 13 de janeiro de 2017 01:22, Euler Taveira <eu...@timbira.com.br> escreveu:
> On 12-01-2017 20:03, Neto pr wrote:
>> Se alguem tiver alguma sugestao de como eu poderia armazenar a saida
>> do explain analyse no sgbd diretamente, seria otimo, mas gostaria que
>> isso fosse de forma granular, ou seja, cada item do comando explain,
>> em campos especificos (nao necessariamente todos os itens)
>>
> Que tal modificar o auto_explain e salvar direto em uma tabela do banco?
>
A principio nao consegui sacar como fazer isso.
Pelo que vi o auto-explain permite alterar o formato de Saida (xml,
json, text), duracao da query para se registrar log e mais algumas
configuracoes relacionadas ao registro de logs em arquivo.
Caso tenha como alterar para salvar direto no banco, me interessa saber.

 []`s
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] armazenar Plano execução

[Neto pr]

Em 12 de janeiro de 2017 13:49, Roberto Mello
<roberto.me...@gmail.com> escreveu:
> 2017-01-12 10:24 GMT-04:00 Neto pr <neto...@gmail.com>:
>>
>>
>> Cleiton, acho que ira servir sim.
>>
>> Como preciso dos dados do Explain Analyse disponivel para uma
>> aplicacao JAVA, a principio pensei em armazenar o resultado do
>> Auto-Explain em um
>> arquivo XML, e apos a aplicacao ira ler esse arquivo. Como o XML cria
>
>
> Já pensou em armazenar no próprio banco?
>
Roberto, o meu objetivo inicialmente era armazenar a saida do comando
explain analyse diretamente no Banco, mas nao em texto puro, gostaria
de algo como, custo total em um campo, numero de linhas em outro
campo, etc.

> E XML? Existe vida fora do XML. Talvez um formato mais simples e fácil de
> parse.

Como nao encontrei uma forma de armazenar a saida do explain
diretamente no banco, pensei em utilizar o Auto-explain, com saida
para arquivo xml, para apos isso, armazenar no banco.

Se alguem tiver alguma sugestao de como eu poderia armazenar a saida
do explain analyse no sgbd diretamente, seria otimo, mas gostaria que
isso fosse de forma granular, ou seja, cada item do comando explain,
em campos especificos (nao necessariamente todos os itens)

[]`s
>
> Roberto
>
> ___
> 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

Re: [pgbr-geral] armazenar Plano execução

[Neto pr]

Em 10 de janeiro de 2017 12:02, Cleiton Luiz Domazak
<cleitondoma...@gmail.com> escreveu:
>
>
> 2017-01-10 11:35 GMT-02:00 Neto pr <neto...@gmail.com>:
>>
>> Ola pessoal
>>
>> No meu trabalho de Pós, preciso armazenar os planos de execucoes das
>> consultas submetidas (explain consulta).
>> Nao gostaria de armazenar o plano de execucao em texto puro, pois
>> somente alguns dados que me interessam, como por exemplo o custo total
>> da consulta.
>>
>> Alguem tem alguma sugestao para armazenar o plano de execucao no banco
>> de dados, separado em campos como: textosql, custo total, tempo,
>> etc...
>
>
> Dê uma olhada no [1] auto_explain se não lhe atende

Cleiton, acho que ira servir sim.

Como preciso dos dados do Explain Analyse disponivel para uma
aplicacao JAVA, a principio pensei em armazenar o resultado do
Auto-Explain em um
arquivo XML, e apos a aplicacao ira ler esse arquivo. Como o XML cria
tags para cada item, fica facil extrair por exemplo o custo total
 (tag ) e outras info...

Antes disso pensei no comando COPY[1] abaixo, mas acho que nao serve
para comando Explain Analyse.

COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;

Enfim, como nao encontrei outra opcao, vou tentar exportar XML e ler o
arquivo, para apos armazenar no Banco de dados.

-- saida do log para query: select
pg_sleep((select 1)); ---

LOG:  duration: 1007.321 ms  plan:
http://www.postgresql.org/2009/explain;>
  select pg_sleep((select 1));
  
Result
0.01
0.03
1
0
1007.210
1007.211
1
1

  
Result
InitPlan
InitPlan 1 (returns $0)
0.00
0.01
1
0
0.032
0.033
1
1
  

  


[1] https://www.postgresql.org/docs/9.3/static/runtime-config-logging.html

>
>>
>> Caso nao encontre uma solucao melhor, vou ter que varrer a string
>> texto (saida do comando explain), para encontrar o custo total, tempo
>> etc.. para apos armazenar em uma tabela no banco de dados.
>>
>> []`s Neto
>
>
> 1- https://www.postgresql.org/docs/9.2/static/auto-explain.html
>>
>> ___
>> 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

[pgbr-geral] armazenar Plano execução

[Neto pr]

Ola pessoal

No meu trabalho de Pós, preciso armazenar os planos de execucoes das
consultas submetidas (explain consulta).
Nao gostaria de armazenar o plano de execucao em texto puro, pois
somente alguns dados que me interessam, como por exemplo o custo total
da consulta.

Alguem tem alguma sugestao para armazenar o plano de execucao no banco
de dados, separado em campos como: textosql, custo total, tempo,
etc...

Caso nao encontre uma solucao melhor, vou ter que varrer a string
texto (saida do comando explain), para encontrar o custo total, tempo
etc.. para apos armazenar em uma tabela no banco de dados.

[]`s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Neto pr]

Em 3 de janeiro de 2017 13:21, Euler Taveira  escreveu:
> On 02-01-2017 14:10, Guimarães Faria Corcete DUTRA, Leandro wrote:
>> Pergunto-me qual a validade de experimentar questoes de desempenho
>> numa versao tao obsoleta, sendo que quase todas as versoes do
>> PostgreSQL trazem bons avanços.  Creio que seria mais relevante
>> aplicar isso aa v. 10.
>>
> A vantagem é comparar laranja com laranja; mesmo se você disser que
> 9.0.23 não houve avanços de performance.

Isso, penso que para comparar se uma modificação surtiu efeito, tem
que comparar com a mesma versão no caso a 9.0.1...

>
> Contudo, concordo com o Dutra que vale a pena experimentar uma versão
> recente (9.6.1) para apresentar valores mais atuais (já que a versão
> 9.0.1 é de 04/10/2010 -- mais de 6 anos atrás).
>
Pretendo verificar se as modificações realizadas desde a versão 9.0.1
até a atual, modificaram muito o modelo de custos do postgresql, pois
o Patch que estou aplicando, modifica funções de custos, para que
estimativas sejam mais realistas em ambientes com discos SSDs. Caso
tenha sido alterado algo significativo ai sim pretendo testar em
versões mais recentes.

[ ]`s Neto

>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> 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

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Neto pr]

Em 2 de janeiro de 2017 23:33, Tiago José Adami  escreveu:
>> Pergunto-me qual a validade de experimentar questoes de desempenho
>> numa versao tao obsoleta, sendo que quase todas as versoes do
>> PostgreSQL trazem bons avanços.  Creio que seria mais relevante
>> aplicar isso aa v. 10.
>
> Resposta off-topic já que o OP conseguiu resolver seu problema: no

perdão, mas o seria OP ?

> meio acadêmico isso é comum se o mestrando ou doutorando está
> reproduzindo os mesmos passos de um trabalho (ou artigo) anterior.
> Depende muito do que o orientador define - e deseja.

Exato, para não reinventar a roda, estou utilizando o que pesquisas
comprovadas e publicadas já utilizaram, como a do artigo citado:
http://dl.acm.org/citation.cfm?id=2236588 e a partir da onde pararam
pretendo contribuir com algo novo. Estou utilizando a versão 9.0.1
pois o artigo que estou estudando utilizou esta versão e quero
comparar, as diferenças entre uma versão modificada (patch aplicado),
com a versão original.

> Entretanto: concordo que o OP pode incrementar muito seu trabalho
> aplicando estes experimentos em uma versão mais atual. Seria a cereja
> do bolo ;)

ESSA é a ideia, assim que constatar na prática os efeitos da
modificação proposta no artigo, pretendo implementar na ultima versão.

>
> Adami
> ___
> 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

Re: [pgbr-geral] 2 postgresql no mesmo PC

[Neto pr]

Euler, consegui deixar os dois PGSqls executando simultaneamente. No
meu caso a porta 5433 estava liberada em /etc/service/ e deixei o
segundo SGBD nela...

Somente tive que utilizar o parametro abaixo ao iniciar o PSQL para o
banco que utiliza a porta no-default conforme [A]

psql -p 5433

[A] http://postgresql.nabble.com/conexao-na-porta-5433-td2031848.html

[ ]`s
Neto

Em 1 de janeiro de 2017 22:21, Euler Taveira <eu...@timbira.com.br> escreveu:
> On 01-01-2017 21:01, Neto pr wrote:
>> Pergunta, para se ter dois SGBDs executando na mesma maquina, seria
>> somente mudar os diretorios de instalacao, diretorio onde se armazena
>> os dados (data) e a porta?
>>
> Sim.
>
>> Estou utilizando no primeiro a porta 5432, para o segundo poderia utilizar 
>> qual?
>>
> Qualquer uma que não esteja ocupada e que seja >= 1024 (user ports) [1].
> Sugiro escolher alguma que não esteja no /etc/services como por exemplo,
> 5433.
>
>
> [1]
> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> 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] 2 postgresql no mesmo PC

[Neto pr]

Pessoal

No meu trabalho de pos-grad, preciso ter dois SGBDs PostgreSQL
executando no mesmo servidor. Pois sera realizada uma comparacao
utilizando benchmark TPC-H.
- sgbd 1 - versao postgresql 9.0.1 (com patch aplicado)
- sgbd 2 - versao postgresql 9.0.1 (sem patch, versao original site
postgresql.org).

Para compilar e instalar, segui o que esta no tutorial abaixo, no SO
Debian e foi tudo ok.

https://www.vivaolinux.com.br/dica/Instalacao-do-PostgreSQL-913-pelo-pacote-source

Pergunta, para se ter dois SGBDs executando na mesma maquina, seria
somente mudar os diretorios de instalacao, diretorio onde se armazena
os dados (data) e a porta?

Estou utilizando no primeiro a porta 5432, para o segundo poderia utilizar qual?

Qualquer ajuda é bem vinda.

[ ]`s
Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Neto pr]

Pessoal

A principio resolvi o problema. Obrigado pelas dicas...

Segue a solucao caso alguem tenha este problema.


Para compilar os fontes do Postgresql 9.0.1 utilizando GCC-4.9 eu
utilizei  a seguinte diretiva (

./configure -prefix=/opt/postgres9.0 CFLAGS="-Wno-aggressive-loop-optimizations"

o Wno-aggressive-looop-optiimizations desabilita GCCs aggressive loop
optimization, evitando o erro reportado nos  emails  anteriores e na
lista pgsql--general -->
https://www.postgresql.org/message-id/CAOD%3DoQ-
kq3Eg5SOvRYOVxDuqibVWC8R0wEivPsMGcyzZY-nfzA%40mail.gmail.com

Espero que a retirada da GCCs aggressive loop optimization nao cause
nenhum erro de qualquer tipo no SGBD.

[ ]`s Neto


Em 1 de janeiro de 2017 03:20, Neto pr <neto...@gmail.com> escreveu:
> Guimaraes, sobre  patch,  ele implementa o que esta descrito neste paper:
>
> http://dl.acm.org/citation.cfm?id=2236588
>
> Estou desenvolvendo uma pesquisa,no qual sera necessario que o
> Postgresql tenha  essas caracteristicas, que o patch prove,
> modificando o codigo fonte  original. Nao posso migrar para  a ultima
> versao do Postgreesql, devido a questoes do meu trabalho de pesquisa,
> tem  que ser o postgreSQL 9.0.1 com o patch aplicado.
>
> Eu ja testei o postgreSQL com este patch aplicado em uma maquina
> virtual Linux UBUNTU  12.04 e funcionou perfeitamente, pois o Ubuntu
> 12 utiliza gcc-4.7.
>
> Porque preciso instalar o postgresql no Debian? Pois o servidor que
> estou  utilizando HP-ML110 nao suporta  Ubuntu, somente Debian. Ate
> tentei instalar Ubuntu  no serrvidor HP, mas o servidor nao reconhece
> nem a placa de rede quando  utilizo Ubuntu, o mesmo para versoes
> anteriores ao Debian 8.
>
> Espero ter esclarecido as questoes nao detalhadas nas mensagens anteriores.
>
> .
> Indo para o assunto do problema...
>
> No blog Stack-overflow, sugeriram  desabilitar
> --fno-aggressive-loop-optimizations, (
> http://stackoverflow.com/questions/25583549/initdb-initializing-pg-authid-fatal-wrong-number-of-index-expressions/41412048#41412048
>  ) para compilar  o postgresql sem dar erro.
>
> Alguem sabe se isso seria diretivas de compilacao como  abaixo:
>
> ./configure --prefix=/usr CFLAGS="-O"
> ./configure --prefix=/usr CFLAGS="-O0"
> ./configure --prefix=/usr CFLAGS="-O1"
> ./configure --prefix=/usr CFLAGS="-O2"
> ./configure --prefix=/usr CFLAGS="-O3"
>
> Neste link ( 
> https://github.com/zfsonlinux/zfs/commit/0f62f3f9abc4bfa0bcafee9bfa3d55e91dcb371d
> ) tem  algo parecido  com isso, mas nao entendi muito bem como fazer.
>
> qualquer ajuda sera bem vinda.
>
> []`s Neto
>
>
>
>
> Em 1 de janeiro de 2017 02:46, Guimarães Faria Corcete DUTRA, Leandro
> <l...@dutras.org> escreveu:
>> 2016-12-31 21:58 GMT-02:00 Neto pr <neto...@gmail.com>:
>>> Eu preciso dessa versão 9.0.1, pois um pesquisador da alemanha me
>>> enviou, para ajudar na minha pesquisa de Pós-graduação.
>>
>> Te enviou o quê exatamente?
>>
>>
>>> O patch altera
>>> o postgreSQL para diferenciar características  entre HDD e SSD. É para
>>> fins de pesquisa que estou utilizando.
>>
>> Como assim?  Não ficou claro, não para mim ao menos.  Continua
>> parecendo fechamento cognitivo prematuro, quando a pessoa quer a
>> resposta à pergunta errada.
>>
>> Está parecendo mais fácil portar para a última versão?
>>
>>
>> --
>> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
>> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
>> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
>> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
>> ___
>> 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

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Neto pr]

Guimaraes, sobre  patch,  ele implementa o que esta descrito neste paper:

http://dl.acm.org/citation.cfm?id=2236588

Estou desenvolvendo uma pesquisa,no qual sera necessario que o
Postgresql tenha  essas caracteristicas, que o patch prove,
modificando o codigo fonte  original. Nao posso migrar para  a ultima
versao do Postgreesql, devido a questoes do meu trabalho de pesquisa,
tem  que ser o postgreSQL 9.0.1 com o patch aplicado.

Eu ja testei o postgreSQL com este patch aplicado em uma maquina
virtual Linux UBUNTU  12.04 e funcionou perfeitamente, pois o Ubuntu
12 utiliza gcc-4.7.

Porque preciso instalar o postgresql no Debian? Pois o servidor que
estou  utilizando HP-ML110 nao suporta  Ubuntu, somente Debian. Ate
tentei instalar Ubuntu  no serrvidor HP, mas o servidor nao reconhece
nem a placa de rede quando  utilizo Ubuntu, o mesmo para versoes
anteriores ao Debian 8.

Espero ter esclarecido as questoes nao detalhadas nas mensagens anteriores.

.
Indo para o assunto do problema...

No blog Stack-overflow, sugeriram  desabilitar
--fno-aggressive-loop-optimizations, (
http://stackoverflow.com/questions/25583549/initdb-initializing-pg-authid-fatal-wrong-number-of-index-expressions/41412048#41412048
 ) para compilar  o postgresql sem dar erro.

Alguem sabe se isso seria diretivas de compilacao como  abaixo:

./configure --prefix=/usr CFLAGS="-O"
./configure --prefix=/usr CFLAGS="-O0"
./configure --prefix=/usr CFLAGS="-O1"
./configure --prefix=/usr CFLAGS="-O2"
./configure --prefix=/usr CFLAGS="-O3"

Neste link ( 
https://github.com/zfsonlinux/zfs/commit/0f62f3f9abc4bfa0bcafee9bfa3d55e91dcb371d
) tem  algo parecido  com isso, mas nao entendi muito bem como fazer.

qualquer ajuda sera bem vinda.

[]`s Neto




Em 1 de janeiro de 2017 02:46, Guimarães Faria Corcete DUTRA, Leandro
<l...@dutras.org> escreveu:
> 2016-12-31 21:58 GMT-02:00 Neto pr <neto...@gmail.com>:
>> Eu preciso dessa versão 9.0.1, pois um pesquisador da alemanha me
>> enviou, para ajudar na minha pesquisa de Pós-graduação.
>
> Te enviou o quê exatamente?
>
>
>> O patch altera
>> o postgreSQL para diferenciar características  entre HDD e SSD. É para
>> fins de pesquisa que estou utilizando.
>
> Como assim?  Não ficou claro, não para mim ao menos.  Continua
> parecendo fechamento cognitivo prematuro, quando a pessoa quer a
> resposta à pergunta errada.
>
> Está parecendo mais fácil portar para a última versão?
>
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> 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

Re: [pgbr-geral] Erro compilando fontes Postgresql

[Neto pr]

Pessoal
Eu preciso dessa versão 9.0.1, pois um pesquisador da alemanha me
enviou, para ajudar na minha pesquisa de Pós-graduação. O patch altera
o postgreSQL para diferenciar características  entre HDD e SSD. É para
fins de pesquisa que estou utilizando.

Ao compilar, da tudo certo, mas ao fazer INITDB, da o erro abaixo:
-
creating directory p01/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 24MB/153600
creating configuration files ... ok
creating template1 database in p01/pgsql/data/base/1 ... ok
initializing pg_authid ... FATAL:  wrong number of index expressions
STATEMENT:  CREATE TRIGGER pg_sync_pg_database   AFTER INSERT OR
UPDATE OR DELETE ON

pg_database   FOR EACH STATEMENT EXECUTE PROCEDURE flatfile_update_trigger();

child process exited with exit code 1
initdb: removing data directory "p01/pgsql/data"
-

No blog Stack-overflow, sugeriram o seguinte, desabilitar
-fno-aggressive-loop-optimizations, mas não sei como fazer:

==
http://stackoverflow.com/questions/25583549/initdb-initializing-pg-authid-fatal-wrong-number-of-index-expressions/41412048#41412048

I ran into the same problem after compiling postgresql 8.1.4 with gcc 4.9.3.
The problem seems to be the way postgres uses to represent variable
length arrays:

typedef struct
{
int32   size;   /* these fields must match ArrayType! */
int ndim;
int flags;
Oid elemtype;
int dim1;
int lbound1;
int2values[1];  /* VARIABLE LENGTH ARRAY */
} int2vector;   /* VARIABLE LENGTH STRUCT */

In some cases, for loops accessing 'values', GCC assumes that they
will do one iteration at most. Loops like the one below (extracted
from postgres's source code):

ii->ii_NumIndexAttrs = numKeys;
for (i = 0; i < numKeys; i++)
ii->ii_KeyAttrNumbers[i] = indexStruct->indkey.values[i];

might end up being reduced to something like:

ii->ii_NumIndexAttrs = numKeys;
if (numKeys)
ii->ii_KeyAttrNumbers[0] = indexStruct->indkey.values[0];

as deduced by looking at the assembler generated for it:

.L161:
testl   %r12d, %r12d
movl%r12d, 4(%rbx)
jle .L162
movzwl  40(%r13), %eax
movw%ax, 8(%rbx)
.L162:

The problem went away after re-compiling postgres with that
optimization disabled by using -fno-aggressive-loop-optimizations.


Alguém sabe como desabilitar -fno-aggressive-loop-optimizations...
Tentei colocar esse parâmetro antes de compilar o banco, ./configure
-fno-aggressive-loop-optimizations , mas não aceitou... enfim nao sei
como fazer essa desabilitação.

Abraços
Neto



Em 31 de dezembro de 2016 20:05, Guimarães Faria Corcete DUTRA,
Leandro <l...@dutras.org> escreveu:
> 2016-12-31 19:54 GMT-02:00 Neto pr <neto...@gmail.com>:
>>
>> Acho que a dúvida é mais relacionada ao S.O. Linux no entanto o
>> Posgresql é parte do problema que estou enfrentando.
>
> Acho que terás mais ajuda na lista do SO.  Detalhe, Linux é só o
> núcleo; tua dúvida é de uma distribuição GNU/Linux.
>
>
>> Tenho que compilar o SGBD Postgresql 9.0.1 que tem um Patch para esta
>> versão
>
> Como assim?  Versão mais que obsoleta.  Que remendo (/patch/) é esse?
> Porque você precisa disso, afinal?  Parece um problema de fechamento
> cognitivo prematuro.
>
>
>> Alguém poderia me auxiliar em como eu poderia instalar compilar o
>> Debian 9.0.1 no Debian 8, ou como instalar o gcc 4.7 no debian 8 ? Eu
>> estou tentando fazer em uma VM para não desconfigurar o SO instalado
>> num servidor HP-ML110, mas após eu fazer o teste com sucesso, irei
>> aplicar o procedimento no servidor.
>
> Compile na máquina virtual, não?
>
>
> --
> skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
> +55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
> +55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
> BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
> ___
> 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] Erro compilando fontes Postgresql

[Neto pr]

Ola pessoal

Acho que a dúvida é mais relacionada ao S.O. Linux no entanto o
Posgresql é parte do problema que estou enfrentando.
Tenho que compilar o SGBD Postgresql 9.0.1 que tem um Patch para esta
versão e infelizmente a compilação só funciona no gcc-4.7, conforme
bug relatado na lista oficial
https://www.postgresql.org/message-id/17948.1365090...@sss.pgh.pa.us

Utilizo o debian 8 Jessie, que tem disponível nos repositórios apenas o gcc-4.9.
Tentei instalar o gcc-4.7 de duas formas sem sucesso.

***Primeira tentativa ***
Tentei instalar manualmente o gcc baixando o arquivo gcc-4.7.0.tar.gz
Mas ao instalar as bibliotecas de dependencia  (apt-get install
libmpc-dev libmpfr-dev libgmp-dev gcc-multilib )
o debian instala, sem perguntar o  gcc-4.9 e as bibliotecas
solicitadas, são versões compatíveis com o gcc-4.9. Apos tento
executar MAKE
para instalação manual, acontece erros e não e possível instalar manualmente.

*** Segunda Tentativa 
Tentei adicionar repositórios PPA com o gcc-4.7, no arquivo /etc/apt/sourc.list
add-apt-repository ppa:ubuntu-toolchain-r/test  como ensina neste
link: 
http://askubuntu.com/questions/193513/problem-adding-a-ppa-to-install-gcc-4-7

Ao tentar apt-get install gcc-4.7 é solicitado a instalação de várias
dependencias... ao pedir para instalar as dependencias, acontece o
erro abaixo.
--
root@vmhp110deb8:/home/user1# apt-get install gcc-4.7 gcc-4.7-base
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'gcc-4.7-base' for regex 'gcc-4.7'
Package gcc-4.7-base is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'gcc-4.7-base' has no installation candidate
root@vmhp110deb8:/home/user1# add-apt-repository ppa:ubuntu-toolchain-r/test


Tentei achar um repositório que tem o gcc-4.7-base, mas ai pede a
instalacao de outras dependencias, e informa que não encontrou porque
as bibliotecas são
obsoletas, etc.

*** Tentativa ainda nao testada *
Uma outra ideia que tive e baixar o DVD do Debian 7 Wheezy (que acho
que tem gcc-4.7 e todas as dependencias) e adicionar como repositório,
para que o debian encontre todas as dependencias do gcc.4.7 no DVD.
Ainda não testei essa.

Alguém poderia me auxiliar em como eu poderia instalar compilar o
Debian 9.0.1 no Debian 8, ou como instalar o gcc 4.7 no debian 8 ? Eu
estou tentando fazer em uma VM para não desconfigurar o SO instalado
num servidor HP-ML110, mas após eu fazer o teste com sucesso, irei
aplicar o procedimento no servidor.

Qualquer ajuda é bem vinda.

[]`s  Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] monitoramento usando Trigger

[Neto pr]

Olá
Estou fazendo um trabalho acadêmico, onde preciso monitorar durante
uma janela de tempo (configurável pelo usuário) as atividades do SGBD.
Eu sei que tem como olhar os logs, mas não queria trabalhar com
arquivo e sim  com tabelas do banco.

Pergunta, teria como criar uma TRIGGER que para cada comando DML
grava-se em uma tabela qualquer o texto do comando SQL que foi
submetido?

Eu sei que teria como fazer por tabela (exemplo abaixo), mas eu
preciso que seja para qualquer comando DML. Se tivesse como em vez de
nome_tabela colocar all_tables algo assim. Alguém poderia me dar uma
dica.

CREATE TRIGGER tg_comandos
AFTER INSERT OR DELETE OR UPDATE ON nome_tabela
Salvar texto sql na tabela xyz.

Att
Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Mensagem ao aplicar patch

[Neto pr]

Olá, bom dia
Se alguém puder me indicar o que significa essa mensagem que foi
emitida ao aplicar um Patch nos fontes da versão 9.0.1. Eu verifiquei
os arquivos que o Patch altera do código fonte e a principio foram
alterados corretamente.

Mensagem:" (Stripping trailing CRs from patch; use --binary to disable.) "

-- Aplicação do comando e mensagem de alerta 
projeto@neto-pc:~/Downloads/postgresql-9.0.1$ patch -p1 <
/home/projeto/Downloads/patchssdpg/0001-Split-up-page-cost-options-into-read-and-write.patch
(Stripping trailing CRs from patch; use --binary to disable.)
patching file doc/src/sgml/config.sgml
(Stripping trailing CRs from patch; use --binary to disable.)
patching file doc/src/sgml/indexam.sgml
(Stripping trailing CRs from patch; use --binary to disable.)
 .
 .
 .
-

Segue um Trecho do Patch
0001-Split-up-page-cost-options-into-read-and-write.patch

--- ARQUIVO Patch
0001-Split-up-page-cost-options-into-read-and-write.patch
---

From bcbff6ee8f3ca9a1d7128f00831bd0587a38566f Mon Sep 17 00:00:00 2001
From: Daniel Bausch 
Date: Tue, 18 Jan 2011 01:43:50 +0100
Subject: [PATCH 1/9] Split up page cost options into read and write

This allows better adaption to devices with asymmetric response times
when it comes to reading and writing.  SSDs and PCMs are such devices.

New page cost parameters replace the old ones preserving their semantic.
If in the previous version an occourence of seq_page_cost modeled a read
operation then it is replaced by this commit with seq_read_page_cost,
otherwise, if that reference to seq_page_cost modeled a write operation
it is replaced with seq_write_page_cost.  The same logic is used to
replace random_page_cost with random_read_page_cost or
random_write_page_cost respectively.

This is a shorter version of the longer change 9b13c68 against the
master branch.  It does not change the function gincostestimate in
selfuncs.c because in 9.0.1 that function contains a call to
genericcostestimate only while in master it is hand coded and contains
references to the page cost variables.
---
 doc/src/sgml/config.sgml  |  75 +---
 doc/src/sgml/indexam.sgml |  18 ++--
 doc/src/sgml/perform.sgml |  19 ++--
 doc/src/sgml/ref/alter_tablespace.sgml|  12 +--
 doc/src/sgml/release-8.2.sgml |   4 +-
 src/backend/access/common/reloptions.c|   8 +-
 src/backend/optimizer/path/costsize.c | 123 +++---
 src/backend/utils/adt/selfuncs.c  |  16 ++--
 src/backend/utils/cache/spccache.c|  20 ++---
 src/backend/utils/misc/guc.c  |  30 +--
 src/backend/utils/misc/postgresql.conf.sample |   6 +-
 src/bin/psql/tab-complete.c   |   2 +-
 src/include/commands/tablespace.h |   4 +-
 src/include/optimizer/cost.h  |  12 ++-
 src/include/utils/spccache.h  |   4 +-
 src/test/regress/input/tablespace.source  |   6 +-
 src/test/regress/output/tablespace.source |   6 +-
 17 files changed, 230 insertions(+), 135 deletions(-)

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 39be624..4fdd48b 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2264,7 +2264,7 @@ SET ENABLE_SEQSCAN TO OFF;
  scaling them all up or down by the same factor will result in no change
  in the planner's choices.  By default, these cost variables are based on
  the cost of sequential page fetches; that is,
- seq_page_cost is conventionally set to 1.0
+ seq_read_page_cost is conventionally set to 1.0
  and the other cost variables are set with reference to that.  But
  you can use a different scale if you prefer, such as actual execution
  times in milliseconds on a particular machine.
@@ -2282,10 +2282,10 @@ SET ENABLE_SEQSCAN TO OFF;

  

- 
-  seq_page_cost (floating
point)
+ 
+  seq_read_page_cost (floating
point)
   
-   seq_page_cost configuration parameter
+   seq_read_page_cost configuration
parameter
   
   

@@ -2298,10 +2298,10 @@ SET ENABLE_SEQSCAN TO OFF;
   
  

- 
-  random_page_cost (floating
point)
+ 
+  random_read_page_cost (floating
point)
   
-   random_page_cost configuration parameter
+   random_read_page_cost configuration
parameter
   
   

@@ -2313,7 +2313,7 @@ SET ENABLE_SEQSCAN TO OFF;



-Reducing this value relative to seq_page_cost
+Reducing this value relative to seq_read_page_cost
 will cause the system to prefer index scans; raising it will
 make index scans look relatively more expensive.  You can raise
 or lower both values together to change the 

[pgbr-geral] Saber características dos discos via SGBD ?

[Neto pr]

Pessoal
Em uma grande empresa, podem existir N servidores em N máquinas.
Pergunta, teria como via banco de dados, saber que tipo de Disco cada uma tem?
Preciso disso, pois temos maquinas com discos SSDs e  nessas maquinas
pretendemos deixar as tabelas que sofrem mais leituras, pois SSDs sao
mais rapidos para leituras.

Caso nao consiga isso, eu teria que ver isso via S.O. e dai fica mais
dificil, pois pode acontecer também de uma maquina ter 2 discos
diferentes, etc..como saber se determinada tabela está no disco A ou
B.?

Obrigado
Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Uso de índices x tamanho da tabela

[Neto pr]

Olá pessoal
Estou no momento codificando uma ferramenta para automatização da
criação de índices.
Eu sei que tem algumas contrib do postgresql que fazem  isso, mas  é
para um projeto academico, etc.

Eu sei que quando uma tabela é "pequena"mesmo tendo um índice nela, o
otimizador optara  por carregar ela inteira na RAM (ou cache?) e
aplicar os filtros em memoria semicondutora que é mais rápida que um
hdd, até ai tudo bem.

Mas teria como saber um valor  (nem que for aproximado) de tamanho de
tabela, em que seria interessante criar um índice (considerando o
tamanho da ram como referencia)?

Por exemplo se um Servidor de SGBD tem 8 GB de RAM, e uma tabela tem 9
GB também de tamanho, com certeza compensará criar um índice, (isso
considerando que seria retornado somente até 2% dos registros devido
aos filtros do where).

Mas contando que NÃO é só o SGBD que utiliza a Memoria, e que também
existira  outras queries rodando utilizando memória, quanto de tamanho
que uma tabela teria que ter, para um SGBD achar interessante utilizar
um indice ao inves da tabela ser carregada inteira para a RAM?
Considerando um servidor de 8 GB, se a tabela tiver 1 GB, 2 GB, 4 GB,
quanto seria o tamanho mínimo para o otimizador utilizar um indice.

Será que a concorrência no SGBD afetara muito essa conta?

Abraços
Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Algoritmos de Junções X SSD

[Neto pr]

Em 11 de fevereiro de 2016 11:44, Flavio Henrique Araque Gurgel
 escreveu:
>> Aqui eu falei que os SSDs são 100 vezes mais rápidos, mas somente para
>> leitura
>> deixo aqui uma referencia, de pesquisadores da HP que fizeram um estudo,
>> já antigo...
>> http://www.cs.cmu.edu/~damon2007/pdf/graefe07fiveminrule.pdf
>
>
>> Já vi artigos atuais em que os SSDs atuais chegam a ser 1000 vezes mais
>> rápidos Veja na pagina 2  do artigo que o custo de leitura de um SSD
>> é 0,16 ms enquanto que de um HD é 12 ms, ou seja 75 vezes mais rápido.
>
>
> Note que eles são 75 vezes mais rápidos em... latência. Tempo para responder
> a uma requisição aleatória.
> A taxa de transferência, naquela época do estudo, é até mais baixa que os
> discos comuns.
>
>> necessitam de bastante escrita, quando os dados não cabem na
>> RAM, e se
>>
>>
>> Não há escrita em SELECT. Você está falando de temporários? Ajustar
>> o work_mem para a consulta é uma alternativa válida em muitos casos,
>> mesmo quando se tem SSD, que em alguns casos é péssimo em escrita.
>>
>> Estou falando de escrita, que são utilizadas na Junção para armazenar
>> resultados intermediários..
>
>
> Sim, você está falando dos arquivos temporários do PostgreSQL.
>
>> Como os SSD tem performance ruim em escrita, acredito que vou tentar
>> implementar um ambiente hibrido, deixando os HDD para os arquivos
>> write-intensive (temp, logs) assim deixaria SSD somente para tabelas que
>> tenham bastante leitura... vale explicar para quem não tenha experiencia
>> com SSDs que a escrita não tem boa performance,  devido a não
>
>
> A escrita depende muito do tipo de SSD e de controladora.
> Logo, o melhor seria você testar a capacidade dos discos que você tem em
> mãos, antes de fazer suposições.
> Já tive a oportunidade de testar matrizes de SSD que só faltanvam servir o
> cafezinho. Pelo preço que ela custava deveria mesmo era me servir um
> Whiskey.
>
>> possibilidade de sobrescrever ou atualizar dados. Ao invés disso, é
>> realizado o processo conhecido como /erase-before-write/onde um bloco
>> inteiro deve ser apagado e depois os novos dados podem ser escritos nas
>> páginas do bloco, isso significa que todas as outras páginas do bloco
>> (que nao precisariam ser alteradas), precisam ser lidas e, em seguida,
>> escritas novamente. Em um SSD um dado só pode ser escrito em um bloco
>> vazio, por isso o processo de erase-before-write.
>
>
> Controladoras modernas tem algoritmo automático de wear levelling.
> Normalmente isso não é preocupação do usuário.
>
>> Alguem teria uma sugestão de quais seguimentos de arquivos deixaria no
>> SSDs e quais  nos HDs ?
>
>
> Se sua controladora tem taxa ruim de escrita, deixe fora dos SSDs :
> 1) O diretório de logs do PostgreSQL (configurável no postgresql.conf)
> 2) O diretório pg_xlog (praticamente só escrita, sequencial e intensa)
> 3) O diretório pg_stats_tmp (coloque este em RAM mesmo, ele não precisa de
> persistência).
>
> Tudo também vai depender da carga do seu banco de dados, o que ele faz. Em
> alguns casos, criar uma tablespace dentro do SSD e jogar lá só algumas
> tabelas ou índices já é a melhor opção.
>

Ola

Faltou no meu email, falar do ambiente que estou projetando. O
ambiente é um clássico Data warehouse, com 1 carga diária noturna de
INSERT/UPDATE/DELETE, e o restante do tempo será ambiente
read-intensive. Mudei de ideia e não quero mais ambiente SOMENTE SSD,
pretendo seguir o padrão que a maioria usa, ou seja, deixar no HDD, os
segmentos: temp, log.

Mas sendo um ambiente Hibrido (hdd e ssd) se eu mudar o parametro
random_page_cost para 1 (leituras aleatorias = sequencial), então para
os HDD o postgreSQL irá achar que o "custo" da leitura sequencial e
aleatória sao iguais, o que para os HDD estara incorreto, irá
acontecer isso, correto??.  Esse parametro é para o banco inteiro ou
da para setar por tablespace ou segmento ???

Saudações

Neto


> Veja bem, estou respondendo suas perguntas baseado no fim do filme, não na
> história toda. Infelizmente, muita gente faz otimização assim, compra o
> Hardware e depois estuda como enfiar o sistema lá dentro.
> Eu, particularmente, prefiro fazer ao contrário.
>
>
> []s
> Flavio Gurgel
> ___
> 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

Re: [pgbr-geral] Algoritmos de Junções X SSD

[Neto pr]

Em 10 de fevereiro de 2016 07:32, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Pessoal
>>
>> O algoritmo MERGE-JOIN ou HASH-JOIN normalmente é escolhido pelo
>> Otimizador ao inves do NESTED-LOOP, devido a ter melhor desempenho.
>>
>
> Não, ele é escolhido quando tem um custo mais baixo.
> Ok, isso mesmo que eu queria  dizer
>


> No entanto, se considerarmos a utilização de discos SSDs, que tem
>> velocidade de leitura mais de 100 vezes mais rápida que um HDD o
>> algoritmo NESTED-LOOP pode ser uma melhor opção, devido a trabalhar
>> somente com leituras. Outro fato é que o MERGE-JOIN e HASH-JOIN
>>
>
> Se considerarmos que o custo de leitura aleatória é mais baixo, um nested
> loop *pode* ser menos custoso em relação aos outros métodos de acesso.
>
> Discos SSD não são "100x mais rápidos" que discos rotativos. Isso depende
> muito da arquitetura de todo o sistema de armazenamento.
>
> Aqui eu falei que os SSDs são 100 vezes mais rápidos, mas somente para
leitura
deixo aqui uma referencia, de pesquisadores da HP que fizeram um estudo, já
antigo...
http://www.cs.cmu.edu/~damon2007/pdf/graefe07fiveminrule.pdf
Já vi artigos atuais em que os SSDs atuais chegam a ser 1000 vezes mais
rápidos Veja na pagina 2  do artigo que o custo de leitura de um SSD é
0,16 ms enquanto que de um HD é 12 ms, ou seja 75 vezes mais rápido.


> O que é mais interessante nos SSDs é que o "custo"  de leitura aleatória
> (randômica) é próximo, às vezes igual, ao "custo" de leitura sequencial.
>
> necessitam de bastante escrita, quando os dados não cabem na RAM, e se
>>
>
> Não há escrita em SELECT. Você está falando de temporários? Ajustar o
> work_mem para a consulta é uma alternativa válida em muitos casos, mesmo
> quando se tem SSD, que em alguns casos é péssimo em escrita.
>
> Estou falando de escrita, que são utilizadas na Junção para armazenar
resultados intermediários..


> considerarmos o maior preço por gigabyte de um SSDs, isso também deve
>>
>
> O custo que estou falando não é preço (apenas pra ficar claro).


Sim estou falando de dinheiro...

>
>
> ser considerado. Estou considerando ambientes exclusivos com discos SSDs.
>>
>> Alguém sabe se o PostgreSQL consegue identificar se o armazenamento está
>> sendo em um SSD para poder escolher melhor o algoritmo de Junção ?
>>
>
> Você precisa especificar o "custo de fazer leitura em disco". Para isso,
> você precisa ajustar os parâmetros random_page_cost e seq_page_cost do seu
> servidor de banco de dados.
>
> Muitos administradores tem colocado 1 como random_page_cost quando
> trabalha com SSDs, ou seja, assume-se que a leitura aleatória tem o mesmo
> "custo" que a leitura sequencial.
>

Excelente opção.

>
> No seu caso, você precisa testar. Abra uma sessão psql, altere os valores
> nesta sessão com SET, e teste suas consultas.
>
> Como os SSD tem performance ruim em escrita, acredito que vou tentar
implementar um ambiente hibrido, deixando os HDD para os arquivos
write-intensive (temp, logs) assim deixaria SSD somente para tabelas que
tenham bastante leitura... vale explicar para quem não tenha experiencia
com SSDs que a escrita não tem boa performance,  devido a não possibilidade
de sobrescrever ou atualizar dados. Ao invés disso, é realizado o processo
conhecido como *erase-before-write* onde um bloco inteiro deve ser apagado
e depois os novos dados podem ser escritos nas páginas do bloco, isso
significa que todas as outras páginas do bloco (que nao precisariam ser
alteradas), precisam ser lidas e, em seguida, escritas novamente. Em um SSD
um dado só pode ser escrito em um bloco vazio, por isso o processo de
erase-before-write.

Alguem teria uma sugestão de quais seguimentos de arquivos deixaria no SSDs
e quais  nos HDs ?
qualquer ajuda sera bem vinda.

[]`s Neto




> []s
> Flavio Gurgel
> ___
> 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] Algoritmos de Junções X SSD

[Neto pr]

Pessoal

O algoritmo MERGE-JOIN ou HASH-JOIN normalmente é escolhido pelo Otimizador
ao inves do NESTED-LOOP, devido a ter melhor desempenho.

No entanto, se considerarmos a utilização de discos SSDs, que tem
velocidade de leitura mais de 100 vezes mais rápida que um HDD o algoritmo
NESTED-LOOP pode ser uma melhor opção, devido a trabalhar somente com
leituras. Outro fato é que o MERGE-JOIN e HASH-JOIN necessitam de bastante
escrita, quando os dados não cabem na RAM, e se considerarmos o maior preço
por gigabyte de um SSDs, isso também deve ser considerado. Estou
considerando ambientes exclusivos com discos SSDs.

Alguém sabe se o PostgreSQL consegue identificar se o armazenamento está
sendo em um SSD para poder escolher melhor o algoritmo de Junção ?

[]`s Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral