Nabble - PostgreSQL

Re: Desempenho no Linux

2009-11-26T04:48:52Z

Pablo Sánchez escreveu:

2009/11/26 Wolak Sistemas - Fabiano Machado Dias fabiano@...:

Pessoal, não vamos esquecer de outros fatores que fazem o Linux ter um
desempenho muito melhor.

- Sistemas de aquivos (Qual a opção que existe no Windows além de NTFS?)


Mas será que precisa de algum outro além desse para ele? (obs, existe
fat32, vc pode compilar partições maiores que 4GB de fat32 utilizando
uma ferramenta chamada fat32format.exe - não é padrão do windows, mas
é gratuita

FAT 32? Bah, tá loco, isso nem deveria ser considerado um sistema de arquivos. E acho que é importante você poder contar com mais opção de file system, já tive situações onde coloquei os dados em XFS, indíces em EXT2, e logs em ReiserFS.
Era um caso específico e a performance ficou melhor, mas me diz qual a opção que teria em Windows? Nenhuma!

- Parâmetros do Kernel (Só se você por um expert no registro do Windows,
quais os parâmetros que você pode mudar?)


Eu faço uma limpeza de alguns parâmetros que já conheço serem
desnecessários e que só deixam o OS mais lento, mas isso desde o winnt
4... então meio que realmente, não sei de muita gente que faça isso na
mão hoje em dia.

Blz, acho que pode até ser válido, agora muda os semáforos do SO, ajusta a memória compartilhada, muda o tamanho da pilha, e outra sem reiniciar o sistema, afinal tu vai derrubar a empresa só pra mudar alguns parâmetros?

- Instalação via código fonte (Sei que tb dá pra compilar no Windows, mas
duvido alguém que faça sem dor de cabeça e tb duvido do desempenho)


Sem dor de cabeça é complicado mesmo, mas vai falar com o Guilherme
Blanco que é o cara responsável pelo windows.php.net. ;-)

- Melhor uso de hardware (Isso é senso comum, o Linux faz uso do hardware de
maneira muito mais otimizada que o Windows)


Senso comum não é comprovação. Os drivers de placas 3D para windows
são no geral muito melhores que o do Linux, até mesmo porque tem
pouquíssima placa com driver oficial para o Linux...

É senso comum que o céu é azul, mas é cientificamente comprovado que
não existem as cores, apenas o espectro de luz. A cor é mera
interpretação do cérebro, e o que é azul para mim (ou seja, exatamente
como meu cérebro me apresenta) poderia ser o verde para vc.

Senso comum é subjetivo, não serve como parâmetro... é a interpretação
ordinária de cada um sobre o que todo mundo fala e quase ninguém para
para comprovar.

Tem pesquisas por aí que suportam a argumentação, e acho que nosso
amigo precisa delas, e não de "senso comum".

Bom quis dizer senso comum porque a maioria das pessoas que trabalham e conhecem o Linux sabem disso, mas só para elucidar o porque posso citar algumas coisas:

- Linux e o Kernel foram feitos para rodar em hardware barato, desde o início a preocupação com performance foi uma constante.
- O uso de memória e processador e a maneira de controlar os processos são melhores que qualquer sistema Windows, até pouco tempo atrás o Windows tinha problema em gerenciar 4 gb de memória.
- Drivers de Placa 3d? Bom estamos ou pelo menos eu estava falando em servidores, onde os drivers realmente importantes são os das controladoras de disco, rede etc...
Lembro de uma situação onde estava instalando um Debian em um servidor Dell, durante a instalação veio uma mensagem dizendo que eu precisaria de um pacote para a atualização do firmware da placa de rede, pois a mesma tinha problemas no driver nativo.
Entrei no repositório de pacotes, baixei, pluguei um pendrive e a instalação continuou e este server está rodando até agora.

Talvez a expressão senso comum não foi a mais correta, mas sei lá até leigos hoje em dia sabem que Linux é mais rápido que Windows, talvez porque é o sistema mais usado em servidores no mundo inteiro, sei lá!

- Segurança (Bom como diz o Telles "Existem 2 tipos de Windows, aquele que
tem vírus e aquele que você acha que não tem vírus")

Para convencer o seu cliente você poderia fazer uma instalação em um
servidor da sua própria em empresa e comparar o desempenho, duvido que ele
não irá se convencer.

Abraço,
Fabiano



Euler Taveira de Oliveira escreveu:

Pablo Sánchez escreveu:


"PostgreSQL performance is very close on both platforms (within 6/100
of a second for 1000 Operations) – It’s faster on Windows and faster
still on Windows with PHP 5.3"



Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O
autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para
isso; eles implementam modelos que simulam um ambiente real de acordo com a
arquitetura (OLTP, OLAP ou Web) do seu sistema.



Não conheço nenhuma diferença... Com exceção do fato de que há
tunnings que podem ser feitos com os semáforos do kernel em
Linux/FreeBSD que não se conseguem no Windows.



Como eu disse esses conceito *não* existe (é emulado) no Windows.




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

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

From forum: PostgreSQL - Brasil

How are blobs (oid) stored?

2009-11-26T04:45:48Z

Hi all,

I know this is none of the user's business, but I'm wondering how
blob's implemented as oid are stored in the postgresql data storage.
Are each of them kept in a separate file, or are they chunked into
pieces and scattered ?

Thanks !

Jerome.

--
Jerome Eteve.
http://www.eteve.net
jerome@...

--
Sent via pgsql-general mailing list (pgsql-general@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

From forum: PostgreSQL - general

Re: Desempenho no Linux

2009-11-26T04:42:10Z

2009/11/26 Pablo Sánchez <phackwer@...>:
> 2009/11/26 Sebastian SWC <sebastianswc@...>:
>> A não ser que ele tenha alguém experiente em FreeBSD na equipe não
>> parece uma boa idéia.
>
> Não sabemos nem se ele tem alguém experiente em Linux na equipe (não
> digo na dele, digo na do cliente).
>

Tudo depende quem gerencia o servidor. Se o cliente deixa tudo por
conta do fornecedor, é possível que não faça diferença desde que tudo
funciona normalmente. Cada caso é um caso. Sem muitos detalhes fica
bem difícil opinar.

--
Atenciosamente,
Sebastian Selau Webber Colombo
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: Desempenho no Linux

2009-11-26T04:38:42Z

2009/11/26 Sebastian SWC <sebastianswc@...>:
> A não ser que ele tenha alguém experiente em FreeBSD na equipe não
> parece uma boa idéia.

Não sabemos nem se ele tem alguém experiente em Linux na equipe (não
digo na dele, digo na do cliente).

--
=================================
Pablo Santiago Sánchez
Análise e Desenvolvimento de Sistemas Web
Zend Certified Engineer #ZEND006757
phackwer@...
(61) 9975-0883
http://www.sansis.com.br
http://www.corephp.com.br
"Quidquid latine dictum sit, altum viditur"
=================================
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: Desempenho no Linux

2009-11-26T04:37:51Z

2009/11/26 Sebastian SWC <sebastianswc@...>:
> Se o cliente questiona o custo do software dê a sugestão de linux
> "pago" como o RedHat, etc, etc. Com todas as respostas na mão o
> cliente não tem como negar a migração do sistema operacional. O único
> motivo que pode impedir é que o cliente utilize essa máquina para
> outro proposito secundário e não tenha como colocar esses serviços em
> outra máquina/servidor.

Considerando o fato do servidor já ser dedicado, acho que não vai ser
problema. Tem que ver é se o pessoal da rede vai dar conta ou topar o
desafio... Espero que eles topem.

--
=================================
Pablo Santiago Sánchez
Análise e Desenvolvimento de Sistemas Web
Zend Certified Engineer #ZEND006757
phackwer@...
(61) 9975-0883
http://www.sansis.com.br
http://www.corephp.com.br
"Quidquid latine dictum sit, altum viditur"
=================================
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: Desempenho no Linux

2009-11-26T04:36:43Z

2009/11/26 Pablo Sánchez <phackwer@...>:
<corte>
>> Enfim... o jeito é fazer benchmarks próprios para verificar o
>> desempenho entre os dois SO. Uma vantagem que visualizo com a troca
>> para Linux é que não existirá muita coisa rodando como serviço, coisa
>> que infelizmente o Windows possui desde a sua concepção.
>
> Não é bem assim... O Linux tb tem vários processos rodando à toa por
> lá. Se quer usar um OS para isso, te aconselho FreeBSD ao invés do
> Linux.
>

A não ser que ele tenha alguém experiente em FreeBSD na equipe não
parece uma boa idéia.

--
Atenciosamente,
Sebastian Selau Webber Colombo
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: Query times change by orders of magnitude as DB ages

2009-11-26T04:36:16Z

Hello,

2009/11/25 Richard Neill <rn214@...>:

Also, if you find odd statistics of freshly analyzed table - try
increasing statistics target, using
ALTER TABLE .. ALTER COLUMN .. SET STATISTICS ...

If you're using defaults - it's again low for large tables. Start with
200, for example.

Best regards,
Sergey Aleynikov

--
Sent via pgsql-performance mailing list (pgsql-performance@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

From forum: PostgreSQL - performance

Error on VACCUM ANALYZE

2009-11-26T04:34:58Z

Hi All,

I am facing the below error when executing “VACCUM ANALYZE” on the several tables and also the entire PostgreSQL database hanging up and not responding.

WARNING: worker took too long to start; cancelled

I am using PostgreSQL 8.3.5 on windows 32 bit machine.

Any help would be highly appreciated.

Many thanks in advance.

From forum: PostgreSQL - general

Re: Desempenho no Linux

2009-11-26T04:34:15Z

2009/11/26 Pablo Sánchez <phackwer@...>:
<corte>

>
> Eu acho que tem que fazer uma análise um pouco mais profunda do que
> poderia estar acontecendo. Sugerir a troca do OS que o cliente já
> adquiriu licença e tem suporte (deve ter algum admin lá windowzer) é
> complicado. "Vamos usar este, que é de graça e é melhor". Poucas
> pessoas entendem que esse "de graça" não é realmente de graça - quem
> vai administrar o servidor? - e mais ainda, que neste caso o "de
> graça" realmente é melhor (de graça o santo desconfia que é
> des-graça).
>

Se o cliente questiona o custo do software dê a sugestão de linux
"pago" como o RedHat, etc, etc. Com todas as respostas na mão o
cliente não tem como negar a migração do sistema operacional. O único
motivo que pode impedir é que o cliente utilize essa máquina para
outro proposito secundário e não tenha como colocar esses serviços em
outra máquina/servidor.

--
Atenciosamente,
Sebastian Selau Webber Colombo
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: Desempenho no Linux

2009-11-26T04:31:42Z

2009/11/26 Tiago Adami <adamitj@...>:
>> (corte das mensagens anteriores)
>>
>
> Respondendo à todos os posts (economizando texto):
>
> A idéia de que o PostgreSQL foi feito _para_ linux e _portado_ para o
> Windows está baseada no fato de que foi desenvolvido sob a licença
> BSD, portanto _assumi_ que dificilmente os desenvolvedores iniciais
> estivessem utilizando Windows (me corrijam se estiver errado).

Na verdade, ele foi desenvolvido para os BSDs (FreeBSD, por exemplo,
ou outros Unices derivados do BSD mesmo) e depois portado para o
Linux, ou seja, afirmar que é melhor no Linux porque para o Windows
foi portado é o mesmo que dizer que no Linux não seria bom, já que ele
também foi portado para o Linux.

Vide a história do PostgreSQL, e vai ver que em 1987 não existia
Linux... mas já tinha os BSDs (não o Free, nem o Open, nem o Net, que
só vieram anos depois que a universidade de Berkeley liberou as
BSDTapes.., mas mesmo assim, esses são sistemas derivados do código
original de 1969...)

> Já investigamos a causa da lentidão antes. Aparentemente não há nada
> de incomum, apenas a velocidade para consultas simples (cadastros de
> itens, por exemplo) torna-se baixa e tarefas como gravação de nota
> fiscal que levavam segundos passam a demorar minutos.

Já checou se o HD está ok? Problemas físicos podem fazer com que o HD
fique tentando gravar e gravar e gravar e desvie de setores
defeituosos para localizar alguns pouco blocks que estejam ok.

> São mais de 30 usuários simultâneos em um sistema cliente/servidor
> (conecta ao fazer login, desconecta ao fechar o aplicativo). O volume
> transacional é considerado alto, visto que a todo momento alguma
> operação é feita nos terminais simultaneamente.
>
> Também, não conseguimos identificar nenhum outro aplicativo que faça o
> consumo de recursos do servidor. Mas...
>
> ... o array dos dois discos que contém o banco possui pastas
> compartilhadas sim, e com muitos arquivos nela. Isto passou
> despercebido em um primeiro momento. Mesmo assim, a atividade nestas
> pastas é muito pequena, não justifica a queda de desempenho tão brusca
> que ocorreu de uns dias para cá.
>
> Enfim... o jeito é fazer benchmarks próprios para verificar o
> desempenho entre os dois SO. Uma vantagem que visualizo com a troca
> para Linux é que não existirá muita coisa rodando como serviço, coisa
> que infelizmente o Windows possui desde a sua concepção.

Não é bem assim... O Linux tb tem vários processos rodando à toa por
lá. Se quer usar um OS para isso, te aconselho FreeBSD ao invés do
Linux.

--
=================================
Pablo Santiago Sánchez
Análise e Desenvolvimento de Sistemas Web
Zend Certified Engineer #ZEND006757
phackwer@...
(61) 9975-0883
http://www.sansis.com.br
http://www.corephp.com.br
"Quidquid latine dictum sit, altum viditur"
=================================
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: cvs chapters in our docs

2009-11-26T04:30:22Z

On Thu, Nov 26, 2009 at 6:44 AM, Magnus Hagander <magnus@...> wrote:

> On Thu, Nov 26, 2009 at 12:29, Robert Haas <robertmhaas@...> wrote:
>> On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut <peter_e@...> wrote:
>>> On ons, 2009-11-25 at 22:15 +0100, Magnus Hagander wrote:
>>>> On Wed, Nov 25, 2009 at 22:07, Peter Eisentraut <peter_e@...> wrote:
>>>> > On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
>>>> >> Attached is a patch which adds a chapter to git in our documentation,
>>>> >> around where we have several chapters about cvs today. It also removes
>>>> >> a few very out of date comments about cvs
>>>> >
>>>> > I think this whole chapter could be removed and the relevant information
>>>> > added to the web site or the wiki.
>>>> >
>>>> > (Btw., it's spelled Git, not GIT.)
>>>>
>>>> Completely, or replaced with a reference to pages on the web/wiki?
>>>
>>> I think the appendix in question could be removed completely, if the
>>> content is adequately covered elsewhere.
>>>
>>> In the installation instructions chapter, there is a section "Getting
>>> the Source", which could warrant a link or reference to the appropriate
>>> instructions on the web site.
>>
>> I have to say I'm not really impressed by the idea of removing things
>> from our documentation and replacing them with pages on the wiki. The
>> documentation is better-written and easier to navigate. Yeah, the
>> part about 28K modems is pretty silly, but we can fix that without
>> throwing the baby out with the bathwater...
>
> Well, my original suggestion had it still there, just not the
> documentation that's not really ours to maintain (like how tags and
> branches work in cvs). Are you ok with that path? (We already
> reference the wiki for "how to work with CVS", so there is nothing new
> there)

Barring protests, I tend to agree that there's little point in keeping
the CVSup documentation around. I don't think it would be a bad thing
to have a little bit of well-written documentation on CVS branches and
tags, especially if it covered things like our particular tagging and
branching conventions. But the current contents of that page don't
appear to be worth much, so I don't think we'd be losing much if we
got rid of it. Of course if someone wanted to rewrite it to be more
useful that might be even better, but I'm not sure anyone wants to put
in the effort.

...Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From forum: PostgreSQL - hackers

Re: Desempenho no Linux

2009-11-26T04:30:02Z

2009/11/25 Tiago Adami <adamitj@...>:
> Olá pessoal. Antes de começar, quero dizer que não sou xiita e
> tampouco quero transformar este post em uma discussão sobre qual SO é
> melhor por um ou outro motivo. Quero que o foco seja restrito apenas
> ao uso do PostgreSQL.
>
> Temos um cliente com uma base de dados onde o arquivo de backup no
> formato compactado com "-F c -Z 9" tem próximo de 400 MB. Eu sei que
> para o padrão de vocês é pouco, mas para nossa aplicação já é um
> tamanho grande.

Tenhos clientes com dumps menores que esse... :P

> O servidor do cliente é Windows 2008 64 bits, rodando
> em um servidor Dell com Intel Xeon 3 Ghz de 4 núcleos e 4 GB de RAM e
> um disco SCSI (sem RAID).

Poxa, isso faz diferença. Nesse windão deve ter alguns
compartilhamentos e serviços. Todos concorrendo com o postgres.

>
> Neste servidor havia reclamações de lentidão. Acontecia em um
> determinado horário (das 16:00hs em diante), e nada de anormal
> aparecia no status do servidor (observado pelo pgAdmin). Existiam
> apenas transações abertas desde às 08:00 hs da manhã no modo "In
> Transaction" ou "Idle".

A query estava 'in transaction' desde as 8h e ficou "pendurada" até
agora? já descrobriu a causa disso?

> Mas de uns dias para cá, a lentidão passou a
> ser incessante, mesmo sem atualizações do aplicativo, e não há
> backup/restore ou vacuum que resolva. A versão atual rodando é a
> 8.2.13.
>
> Primeiro, sugerimos a atualização para a versão 8.3.8 (homologada para
> o nosso ERP, a 8.4.1 nem está em testes ainda). Mas sinceramente, este
> é o primeiro passo apenas...

Mudar a versão pode trazer alguns ganhos de desempenho, mas se você
utiliza o padrão do postgresql.conf não deve ser grande a diferença. É
o seu caso?

<corte>
--
Atenciosamente,
Sebastian Selau Webber Colombo
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: How to start the "auto_explain" module

2009-11-26T04:26:37Z

In response to aymen marouani :
> Hi,
> In order to profile my Postgres queries, I used
> the "auto_explain.log_min_duration (integer)".
> How can I load the auto_explain module ?
> Thanks in advance.

http://www.depesz.com/index.php/2008/11/23/waiting-for-84-auto-explain/

Read that.

Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: -> Header)
GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99

--
Sent via pgsql-sql mailing list (pgsql-sql@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

From forum: PostgreSQL - sql

Re: Desempenho no Linux

2009-11-26T04:25:32Z

2009/11/26 Pablo Sánchez <phackwer@...>:
>> - Segurança (Bom como diz o Telles "Existem 2 tipos de Windows, aquele que
>> tem vírus e aquele que você acha que não tem vírus")

tab + enter por acidente, desculpem.

Bom, então estou na segunda parcela, porque nem entro mais no windows
do meu note, só para jogar e muito de vez em quando, hehehe.

>> Para convencer o seu cliente você poderia fazer uma instalação em um
>> servidor da sua própria em empresa e comparar o desempenho, duvido que ele
>> não irá se convencer.

Isso é verdade. A apresentação seria essencial. Mas aí vem a questão
da realização dos testes e do cliente não achar que o teste foi
maquiado ou manipulado, afinal de contas, ele está tentando salvar a
reputação do sistema da empresa que não está rodando bem com a
afirmação de que a culpa é de software de terceiros.

Eu acho que tem que fazer uma análise um pouco mais profunda do que
poderia estar acontecendo. Sugerir a troca do OS que o cliente já
adquiriu licença e tem suporte (deve ter algum admin lá windowzer) é
complicado. "Vamos usar este, que é de graça e é melhor". Poucas
pessoas entendem que esse "de graça" não é realmente de graça - quem
vai administrar o servidor? - e mais ainda, que neste caso o "de
graça" realmente é melhor (de graça o santo desconfia que é
des-graça).

--
=================================
Pablo Santiago Sánchez
Análise e Desenvolvimento de Sistemas Web
Zend Certified Engineer #ZEND006757
phackwer@...
(61) 9975-0883
http://www.sansis.com.br
http://www.corephp.com.br
"Quidquid latine dictum sit, altum viditur"
=================================
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: Desempenho no Linux

2009-11-26T04:20:06Z

2009/11/26 Wolak Sistemas - Fabiano Machado Dias <fabiano@...>:
> Pessoal, não vamos esquecer de outros fatores que fazem o Linux ter um
> desempenho muito melhor.
>
> - Sistemas de aquivos (Qual a opção que existe no Windows além de NTFS?)

Mas será que precisa de algum outro além desse para ele? (obs, existe
fat32, vc pode compilar partições maiores que 4GB de fat32 utilizando
uma ferramenta chamada fat32format.exe - não é padrão do windows, mas
é gratuita)

> - Parâmetros do Kernel (Só se você por um expert no registro do Windows,
> quais os parâmetros que você pode mudar?)

Eu faço uma limpeza de alguns parâmetros que já conheço serem
desnecessários e que só deixam o OS mais lento, mas isso desde o winnt
4... então meio que realmente, não sei de muita gente que faça isso na
mão hoje em dia.

> - Instalação via código fonte (Sei que tb dá pra compilar no Windows, mas
> duvido alguém que faça sem dor de cabeça e tb duvido do desempenho)

Sem dor de cabeça é complicado mesmo, mas vai falar com o Guilherme
Blanco que é o cara responsável pelo windows.php.net. ;-)

> - Melhor uso de hardware (Isso é senso comum, o Linux faz uso do hardware de
> maneira muito mais otimizada que o Windows)

Senso comum não é comprovação. Os drivers de placas 3D para windows
são no geral muito melhores que o do Linux, até mesmo porque tem
pouquíssima placa com driver oficial para o Linux...

É senso comum que o céu é azul, mas é cientificamente comprovado que
não existem as cores, apenas o espectro de luz. A cor é mera
interpretação do cérebro, e o que é azul para mim (ou seja, exatamente
como meu cérebro me apresenta) poderia ser o verde para vc.

Senso comum é subjetivo, não serve como parâmetro... é a interpretação
ordinária de cada um sobre o que todo mundo fala e quase ninguém para
para comprovar.

Tem pesquisas por aí que suportam a argumentação, e acho que nosso
amigo precisa delas, e não de "senso comum".

> - Segurança (Bom como diz o Telles "Existem 2 tipos de Windows, aquele que
> tem vírus e aquele que você acha que não tem vírus")
>
> Para convencer o seu cliente você poderia fazer uma instalação em um
> servidor da sua própria em empresa e comparar o desempenho, duvido que ele
> não irá se convencer.
>
> Abraço,
> Fabiano
>
>
>
> Euler Taveira de Oliveira escreveu:
>
> Pablo Sánchez escreveu:
>
>
> "PostgreSQL performance is very close on both platforms (within 6/100
> of a second for 1000 Operations) – It’s faster on Windows and faster
> still on Windows with PHP 5.3"
>
>
>
> Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O
> autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para
> isso; eles implementam modelos que simulam um ambiente real de acordo com a
> arquitetura (OLTP, OLAP ou Web) do seu sistema.
>
>
>
> Não conheço nenhuma diferença... Com exceção do fato de que há
> tunnings que podem ser feitos com os semáforos do kernel em
> Linux/FreeBSD que não se conseguem no Windows.
>
>
>
> Como eu disse esses conceito *não* existe (é emulado) no Windows.
>
>
>
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@...
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>

--
=================================
Pablo Santiago Sánchez
Análise e Desenvolvimento de Sistemas Web
Zend Certified Engineer #ZEND006757
phackwer@...
(61) 9975-0883
http://www.sansis.com.br
http://www.corephp.com.br
"Quidquid latine dictum sit, altum viditur"
=================================
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: Desempenho no Linux

2009-11-26T04:13:41Z

2009/11/26 Euler Taveira de Oliveira <euler@...>:
> Pablo Sánchez escreveu:
>> "PostgreSQL performance is very close on both platforms (within 6/100
>> of a second for 1000 Operations) – It’s faster on Windows and faster
>> still on Windows with PHP 5.3"
>>
> Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O
> autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para
> isso; eles implementam modelos que simulam um ambiente real de acordo com a
> arquitetura (OLTP, OLAP ou Web) do seu sistema.

Acho que o teste foi mais para medir o PHP que o PostgreSQL mesmo...
Ainda assim, não é um teste muito profundo mesmo não...

--
=================================
Pablo Santiago Sánchez
Análise e Desenvolvimento de Sistemas Web
Zend Certified Engineer #ZEND006757
phackwer@...
(61) 9975-0883
http://www.sansis.com.br
http://www.corephp.com.br
"Quidquid latine dictum sit, altum viditur"
=================================
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: Query times change by orders of magnitude as DB ages

2009-11-26T04:11:54Z

Hello,

2009/11/25 Richard Neill <rn214@...>:

>It's a simple query, but using a complex view. So I can't really re-order it.
View is inserted directly into your query by PG, and then reordered
according to from_collapse_limit. Probably, problems lies in the view?
How good is it performing? Or from_collapse_limit is _too low_, so
view isn't expanded right?

>Are you saying that this means that the query planner frequently makes the wrong choice here?
Look at explain analyze. If on some step estimation from planner
differs by (for start) two order of magnitude from what's really
retrieved, then there's a wrong statistics count. But if, on every
step, estimation is not too far away from reality - you suffer from
what i've described - planner can't reoder efficiently enough query.
Because of it happen sometimes - i suspect gego. Or wrong statistics.

>I hadn't changed it from the defaults; now I've changed it to:
> autovacuum_max_workers = 6
> autovacuum_vacuum_scale_factor = 0.002
> autovacuum_analyze_scale_factor = 0.001

If your tables are not >100mln rows, that's agressive enough. On
100mln rows, this'd analyze table every 100k changed
(inserted/updated/deleted) rows. Is this enough for you? Default on
large tables are definatly too low. If you get now consistent times -
then you've been hit by wrong statistics.

Best regards,
Sergey Aleynikov

--
Sent via pgsql-performance mailing list (pgsql-performance@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

From forum: PostgreSQL - performance

Re: Desempenho no Linux

2009-11-26T04:09:34Z

> (corte das mensagens anteriores)
>

Respondendo à todos os posts (economizando texto):

A idéia de que o PostgreSQL foi feito _para_ linux e _portado_ para o
Windows está baseada no fato de que foi desenvolvido sob a licença
BSD, portanto _assumi_ que dificilmente os desenvolvedores iniciais
estivessem utilizando Windows (me corrijam se estiver errado).

Já investigamos a causa da lentidão antes. Aparentemente não há nada
de incomum, apenas a velocidade para consultas simples (cadastros de
itens, por exemplo) torna-se baixa e tarefas como gravação de nota
fiscal que levavam segundos passam a demorar minutos.

São mais de 30 usuários simultâneos em um sistema cliente/servidor
(conecta ao fazer login, desconecta ao fechar o aplicativo). O volume
transacional é considerado alto, visto que a todo momento alguma
operação é feita nos terminais simultaneamente.

Também, não conseguimos identificar nenhum outro aplicativo que faça o
consumo de recursos do servidor. Mas...

... o array dos dois discos que contém o banco possui pastas
compartilhadas sim, e com muitos arquivos nela. Isto passou
despercebido em um primeiro momento. Mesmo assim, a atividade nestas
pastas é muito pequena, não justifica a queda de desempenho tão brusca
que ocorreu de uns dias para cá.

Enfim... o jeito é fazer benchmarks próprios para verificar o
desempenho entre os dois SO. Uma vantagem que visualizo com a troca
para Linux é que não existirá muita coisa rodando como serviço, coisa
que infelizmente o Windows possui desde a sua concepção.

--
TIAGO J. ADAMI
http://www.adamiworks.com
_______________________________________________
pgbr-geral mailing list
pgbr-geral@...
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

From forum: PostgreSQL - Brasil

Re: Bug report: pgadmin3-1.10.0 segmentation fault

2009-11-26T04:08:30Z

Thanks - I've committed a fix for this to SVN.

Regards, Dave.

On Tue, Nov 24, 2009 at 4:39 PM, Chris Bainbridge
<chris.bainbridge@...> wrote:

> 2nd post...
>
> The table is actually big, I just mistook it for being small since it
> takes several minutes to load. I think the problem is a race
> condition. The window status bar shows "Refreshing data, please
> wait.", during which time I close the window and get a segmentation
> fault. If I wait for the data to load and then close the window, then
> there is no segmentation fault. Here's a backtrace with line numbers:
>
> Program received signal SIGSEGV, Segmentation fault.
> wxWindowBase::DoUpdateWindowUI (this=0x8e05d58, event=...) at
> ../src/common/wincmn.cpp:2212
> 2212 ../src/common/wincmn.cpp: No such file or directory.
> in ../src/common/wincmn.cpp
> (gdb) bt
> #0 wxWindowBase::DoUpdateWindowUI (this=0x8e05d58, event=...) at
> ../src/common/wincmn.cpp:2212
> #1 0x01124ddc in wxTopLevelWindowBase::DoUpdateWindowUI
> (this=0x8e05d58, event=...)
> at ../src/common/toplvcmn.cpp:406
> #2 0x00ff5272 in wxTopLevelWindowBase::DoGetScreenPosition
> (this=0x8e05d58, x=0x73, y=0x1)
> at ../include/wx/toplevel.h:273
> #3 0x081b9e04 in frmEditGrid::Go (this=0x8e01c30) at ./frm/frmEditGrid.cpp:1295
> #4 0x081b9212 in frmEditGrid::ShowForm (this=0x8e01c30, filter=false)
> at ./frm/frmEditGrid.cpp:1194
> #5 0x081c47f7 in editGridFactoryBase::ViewData (this=0x8d463b8,
> form=0x8895418, obj=0x8e31600,
> filter=false) at ./frm/frmEditGrid.cpp:3050
> #6 0x081c4c17 in editGridFactory::StartDialog (this=0x8d463b8,
> form=0x8895418, obj=0x8e31600)
> at ./frm/frmEditGrid.cpp:3067
> #7 0x0819bb6d in frmMain::OnAction (this=0x8895418, ev=...) at
> ./frm/events.cpp:147
> #8 0x008172cf in wxAppConsole::HandleEvent (this=0x8784450,
> handler=0x8895418, func=0x8e05d58, event=...)
> at ../src/common/appbase.cpp:322
> #9 0x008d5999 in wxEvtHandler::ProcessEventIfMatches (entry=...,
> handler=0x8895418, event=...)
> at ../src/common/event.cpp:1231
> #10 0x008d5cf8 in wxEvtHandler::SearchDynamicEventTable
> (this=0x8895418, event=...)
> at ../src/common/event.cpp:1413
> #11 0x008d7215 in wxEvtHandler::ProcessEvent (this=0x8895418,
> event=...) at ../src/common/event.cpp:1289
> #12 0x008d71d9 in wxEvtHandler::ProcessEvent (this=0x8895634,
> event=...) at ../src/common/event.cpp:1300
> #13 0x0112a9b9 in wxWindowBase::TryParent (this=0x8d21608, event=...)
> at ../src/common/wincmn.cpp:2661
> #14 0x008d71e9 in wxEvtHandler::ProcessEvent (this=0x8d21608,
> event=...) at ../src/common/event.cpp:1306
> #15 0x011204be in wxToolBarBase::OnLeftClick (this=0x8d21608, id=1250,
> toggleDown=false)
> at ../src/common/tbarbase.cpp:596
> #16 0x01085d1d in gtk_toolbar_callback (widget=0x8807a00,
> tool=0x8d46da8) at ../src/gtk/tbargtk.cpp:197
> #17 0x00b989fc in g_cclosure_marshal_VOID__VOID () from
> /usr/lib/libgobject-2.0.so.0
> #18 0x00b8b072 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
> #19 0x00ba07a8 in ?? () from /usr/lib/libgobject-2.0.so.0
> #20 0x00ba1b2d in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
> #21 0x00ba1fb6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
> #22 0x06cd988a in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0
> #23 0x06cdaea8 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #24 0x00b989fc in g_cclosure_marshal_VOID__VOID () from
> /usr/lib/libgobject-2.0.so.0
> #25 0x00b896f9 in ?? () from /usr/lib/libgobject-2.0.so.0
> #26 0x00b8b072 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
> #27 0x00ba00b0 in ?? () from /usr/lib/libgobject-2.0.so.0
> #28 0x00ba1b2d in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
> #29 0x00ba1fb6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
> #30 0x06cd992a in gtk_button_released () from /usr/lib/libgtk-x11-2.0.so.0
> #31 0x06cd9963 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #32 0x06d99474 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #33 0x00b896f9 in ?? () from /usr/lib/libgobject-2.0.so.0
> #34 0x00b8b072 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
> #35 0x00ba049e in ?? () from /usr/lib/libgobject-2.0.so.0
> #36 0x00ba19b8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
> #37 0x00ba1fb6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
> #38 0x06eb596e in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #39 0x06d91c20 in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0
> #40 0x06d92ea9 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
> #41 0x00d2962a in ?? () from /usr/lib/libgdk-x11-2.0.so.0
> #42 0x013e6e78 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
> #43 0x013ea720 in ?? () from /lib/libglib-2.0.so.0
> #44 0x013eab8f in g_main_loop_run () from /lib/libglib-2.0.so.0
> #45 0x06d93419 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
> #46 0x00ff1ec8 in wxEventLoop::Run (this=0x88073f0) at ../src/gtk/evtloop.cpp:76
> #47 0x010932ac in wxAppBase::MainLoop (this=0x8784450) at
> ../src/common/appcmn.cpp:312
> #48 0x01093001 in wxAppBase::OnRun (this=0x8e05d58) at
> ../src/common/appcmn.cpp:367
> #49 0x0085f3ea in wxEntry (argc=@0x9596ac, argv=0x8772ae8) at
> ../src/common/init.cpp:460
> #50 0x0085f497 in wxEntry (argc=@0xbffff250, argv=0xbffff2f4) at
> ../src/common/init.cpp:472
> #51 0x0807dc43 in main (argc=1, argv=0xbffff2f4) at ./pgAdmin3.cpp:113
>
> --
> Sent via pgadmin-support mailing list (pgadmin-support@...)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-support
>

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgadmin-support mailing list (pgadmin-support@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-support

From forum: PostgreSQL - pgadmin support

SVN Commit by dpage: r8093 - in branches/REL-1_10_0_PATCHES/pgadmin3: . pgadmin/frm pgadmin/include/frm

2009-11-26T04:07:23Z

Author: dpage

Date: 2009-11-26 12:07:23 +0000 (Thu, 26 Nov 2009)

New Revision: 8093

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=8093&view=rev

Log:
Prevent a crash if the edit grid is closed whilst it
is loading data.

Modified:
branches/REL-1_10_0_PATCHES/pgadmin3/CHANGELOG
branches/REL-1_10_0_PATCHES/pgadmin3/pgadmin/frm/frmEditGrid.cpp
branches/REL-1_10_0_PATCHES/pgadmin3/pgadmin/include/frm/frmEditGrid.h

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

From forum: PostgreSQL - pgadmin hackers

Re: Profiling tool for postgres under win32

2009-11-26T04:05:23Z

On 26/11/2009 5:48 PM, aymen marouani wrote:
> Hi,
> I'm using the Postgres database system version 8.3 for a J2EE application.
> I'd like to profile and monitor in "real time" the status of my queries
> because I notice some slow loading.
> Can anyone tell how to get a "good" profiling tool for the Postgres
> database system ?

I'm not aware of any tools that connect to the database to provide
profiling and monitoring.

What the right course of action is depends on what sort of slowdown
you're encountering. If it's particular activities within the program
that're a problem, then you should probably use logging in your
application to record database activity (including query runtimes) to
see what exactly it's doing.

If it's unpredictable slowdowns in operations that are normally fast,
then you need to look at the database end. Look into locking issues (
see: pg_catalog.pg_locks ), table bloat and VACUUM / autovacuum, and the
possibility of simple concurrent load spikes ( see
pg_catalog.pg_stat_activity ).

Typically what you'll do if you're seeing unpredictably slow queries is
use log_min_duration to log problem statements to the PostgreSQL log,
which you can then analyse. If you enable CSV logging, you can pull the
PostgreSQL log into a database, spreadsheet, or whatever for easier
analysis.

The new auto_explain module in 8.4 is excellent and very helpful too,
since it can help you find out what plans were used to execute problem
queries easily and conveniently.

Of course, this won't help you much if your problem is an application
issuing *huge* numbers of very small queries. You can set Pg to log
every query, but you'll rapidly have an apalling amount of data to troll
through, and it's hard to know which ones are related to user-perceived
slowdowns. Application logging is usually a better option for tracking
this sort of thing down.

Out of interest, how are you talking to PostgreSQL? Hand-written SQL via
JDBC? Hibernate / TopLink / some other ORM (possibly via JPA)?

If you're using Hibernate, just enable its query logging features via
log4j and watch what happens.

--
Craig Ringer

--
Sent via pgsql-sql mailing list (pgsql-sql@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

From forum: PostgreSQL - sql

SVN Commit by dpage: r8092 - in trunk/pgadmin3: . pgadmin/frm pgadmin/include/frm

2009-11-26T04:02:40Z

Author: dpage

Date: 2009-11-26 12:02:39 +0000 (Thu, 26 Nov 2009)

New Revision: 8092

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=8092&view=rev

Log:
Prevent a crash if the edit grid is closed whilst it
is loading data.

Modified:
trunk/pgadmin3/CHANGELOG
trunk/pgadmin3/pgadmin/frm/frmEditGrid.cpp
trunk/pgadmin3/pgadmin/include/frm/frmEditGrid.h

--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

From forum: PostgreSQL - pgadmin hackers

Re: Return next

2009-11-26T03:47:19Z

Bom dia pessoal,

O que o andré falou está dando certo, criei uma outra variável e estou jogando de pouco a pouco na saída..

O que eu precisava era a união dos registros (consigo isso da forma que o andré disse), e precisava recuperar registros dos 3 records de forma aleatória.

Consegui resolver, usei a forma do andré e chamo a procedure assim: select * from procedure() order by random();

Funcionou belezinha =D

Valeww pessoal =)

Jorge Vilela

2009/11/25 Osvaldo Kussama <osvaldo.kussama@...>

2009/11/25 Jorge Vilela <jorge.com.br@gmail.com>:

> Pessoal,
> Hoje precisei criar uma procedure com varios selects, que rodam varios (for
> record in sql loop end loop).
> No fim precisava juntar os records de retorno de todos os selects... Algo
> como:
> FOR record1 IN
> SELECT id, nome, email FROM pessoa ORDER BY RANDOM() LIMIT 5
> LOOP
> //FAZ NADA
> END LOOP;
> FOR record2 IN
> SELECT id, nome, email FROM pessoa ORDER BY RANDOM() LIMIT 3
> LOOP
> //FAZ NADA
> END LOOP;
> FOR record3 IN
> SELECT id, nome, email FROM pessoa ORDER BY RANDOM() LIMIT 2
> LOOP
> //FAZ NADA
> END LOOP;
> RETURN record1+record2+record3 EMBARALHADOS;
>
> Tem como? Dá pra fazer um "merge" embaralhando os records em um só e
> retornando um set of tipos?

O que você quer dizer com isso?
A concatenação dos registros? A união dos registros?

Osvaldo

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

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

From forum: PostgreSQL - Brasil

Re: cvs chapters in our docs

2009-11-26T03:44:53Z

On Thu, Nov 26, 2009 at 12:29, Robert Haas <robertmhaas@...> wrote:

> On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut <peter_e@...> wrote:
>> On ons, 2009-11-25 at 22:15 +0100, Magnus Hagander wrote:
>>> On Wed, Nov 25, 2009 at 22:07, Peter Eisentraut <peter_e@...> wrote:
>>> > On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
>>> >> Attached is a patch which adds a chapter to git in our documentation,
>>> >> around where we have several chapters about cvs today. It also removes
>>> >> a few very out of date comments about cvs
>>> >
>>> > I think this whole chapter could be removed and the relevant information
>>> > added to the web site or the wiki.
>>> >
>>> > (Btw., it's spelled Git, not GIT.)
>>>
>>> Completely, or replaced with a reference to pages on the web/wiki?
>>
>> I think the appendix in question could be removed completely, if the
>> content is adequately covered elsewhere.
>>
>> In the installation instructions chapter, there is a section "Getting
>> the Source", which could warrant a link or reference to the appropriate
>> instructions on the web site.
>
> I have to say I'm not really impressed by the idea of removing things
> from our documentation and replacing them with pages on the wiki. The
> documentation is better-written and easier to navigate. Yeah, the
> part about 28K modems is pretty silly, but we can fix that without
> throwing the baby out with the bathwater...

Well, my original suggestion had it still there, just not the
documentation that's not really ours to maintain (like how tags and
branches work in cvs). Are you ok with that path? (We already
reference the wiki for "how to work with CVS", so there is nothing new
there)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From forum: PostgreSQL - hackers

Re: cvs chapters in our docs

2009-11-26T03:44:19Z

Robert Haas wrote:
> On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut <peter_e@...> wrote:
>> In the installation instructions chapter, there is a section "Getting
>> the Source", which could warrant a link or reference to the appropriate
>> instructions on the web site.
>
> I have to say I'm not really impressed by the idea of removing things
> from our documentation and replacing them with pages on the wiki. The
> documentation is better-written and easier to navigate.

I agree in general, but information about version control isn't really
part of the product. For example, if we switch from CVS to Git, and
decide to pull the plug on the CVS server (hypotethically; in reality
I'm sure we'd leave the CVS server around for historical purposes), the
information becomes obsolete.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From forum: PostgreSQL - hackers

Re: odbc driver leaks memory when connection failed

2009-11-26T03:34:16Z

shoji.morimoto@... wrote:
> Thank you very much for your quick support.
>
>> I would commit the change to cvs.
>
> When do you estimate the date of official release ?

In ten days or so, maybe.

regards,
Hiroshi Inoue

--
Sent via pgsql-odbc mailing list (pgsql-odbc@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

From forum: PostgreSQL - odbc

Re: cvs chapters in our docs

2009-11-26T03:29:10Z

On Thu, Nov 26, 2009 at 2:28 AM, Peter Eisentraut <peter_e@...> wrote:

> On ons, 2009-11-25 at 22:15 +0100, Magnus Hagander wrote:
>> On Wed, Nov 25, 2009 at 22:07, Peter Eisentraut <peter_e@...> wrote:
>> > On ons, 2009-11-25 at 16:27 +0100, Magnus Hagander wrote:
>> >> Attached is a patch which adds a chapter to git in our documentation,
>> >> around where we have several chapters about cvs today. It also removes
>> >> a few very out of date comments about cvs
>> >
>> > I think this whole chapter could be removed and the relevant information
>> > added to the web site or the wiki.
>> >
>> > (Btw., it's spelled Git, not GIT.)
>>
>> Completely, or replaced with a reference to pages on the web/wiki?
>
> I think the appendix in question could be removed completely, if the
> content is adequately covered elsewhere.
>
> In the installation instructions chapter, there is a section "Getting
> the Source", which could warrant a link or reference to the appropriate
> instructions on the web site.

I have to say I'm not really impressed by the idea of removing things
from our documentation and replacing them with pages on the wiki. The
documentation is better-written and easier to navigate. Yeah, the
part about 28K modems is pretty silly, but we can fix that without
throwing the baby out with the bathwater...

...Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From forum: PostgreSQL - hackers

How to start the "auto_explain" module

2009-11-26T03:26:13Z

Hi,

In order to profile my Postgres queries, I used the "auto_explain.log_min_duration (integer)".

How can I load the auto_explain module ?

Thanks in advance.

From forum: PostgreSQL - sql

Re: Replication solution

2009-11-26T03:19:11Z

"Joshua D. Drake" <jd@...> writes:
> http://pgfoundry.org/projects/skytools/

See also: http://wiki.postgresql.org/wiki/Londiste_Tutorial

Regards,
--
dim

--
Sent via pgsql-admin mailing list (pgsql-admin@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

From forum: PostgreSQL - admin

Re: Query times change by orders of magnitude as DB ages

2009-11-26T03:14:14Z

On Wed, 25 Nov 2009, Grzegorz Jaśkiewicz wrote:
> the out of order data layout is primary reason for index bloat. And that happens , and
> gets worse over time once data is more and more distributed. ("random" deletes, etc).

That's not index bloat. Sure, having the table not in the same order as
the index will slow down an index scan, but that's a completely different
problem altogether.

Index bloat is caused by exactly the same mechanism as table bloat. The
index needs to have an entry for every row in the table that may be
visible by anyone. As with the table, it is not possible to
deterministically delete the rows as they become non-visible, so the
index (and the table) will be left with dead entries on delete and update.
The vacuum command performs garbage collection and marks these dead rows
and index entries as free, so that some time in the future more data can
be written to those places.

Index bloat is when there is an excessive amount of dead space in an
index. It can be prevented by (auto)vacuuming regularly, but can only be
reversed by REINDEX (or of course deleting the index, or adding loads of
new entries to fill up the dead space after vacuuming).

Matthew

--
for a in past present future; do
for b in clients employers associates relatives neighbours pets; do
echo "The opinions here in no way reflect the opinions of my $a $b."
done; done
--
Sent via pgsql-performance mailing list (pgsql-performance@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

From forum: PostgreSQL - performance

Re: Bit count

2009-11-26T03:04:21Z

On 2009-11-24, Nathaniel Trellice <naptrel@...> wrote:
> I'd like to use an integer column (16 bits will suffice) to hold a bit-field. I'd like to be able to efficiently count the number of bits set in this field.
>
> Is there a built-in function call I can use? (I can't find one in the manual).

convert it to a text representation of the binary value use regexp_replace to remove the 0s take the length.

> If not, can anyone recommend the most efficient way within postgres to implement the kind of bit-counting tricks found at:

postgres functions can be written in C (if you have superuser
priviledges) seems like overkill though.

--
Sent via pgsql-novice mailing list (pgsql-novice@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice

From forum: PostgreSQL - novice

Re: Desempenho no Linux

2009-11-26T03:03:43Z

Pessoal, não vamos esquecer de outros fatores que fazem o Linux ter um desempenho muito melhor.

- Sistemas de aquivos (Qual a opção que existe no Windows além de NTFS?)
- Parâmetros do Kernel (Só se você por um expert no registro do Windows, quais os parâmetros que você pode mudar?)
- Instalação via código fonte (Sei que tb dá pra compilar no Windows, mas duvido alguém que faça sem dor de cabeça e tb duvido do desempenho)
- Melhor uso de hardware (Isso é senso comum, o Linux faz uso do hardware de maneira muito mais otimizada que o Windows)
- Segurança (Bom como diz o Telles "Existem 2 tipos de Windows, aquele que tem vírus e aquele que você acha que não tem vírus")

Para convencer o seu cliente você poderia fazer uma instalação em um servidor da sua própria em empresa e comparar o desempenho, duvido que ele não irá se convencer.

Abraço,
Fabiano

Euler Taveira de Oliveira escreveu:

Pablo Sánchez escreveu:

"PostgreSQL performance is very close on both platforms (within 6/100
of a second for 1000 Operations) – It’s faster on Windows and faster
still on Windows with PHP 5.3"

Ugh?! Quem disse que 'SELECT * FROM tabela' mede performance de um SGBD? O
autor deve estar brincando, né? Temos benchmarks padronizados (aka TPC) para
isso; eles implementam modelos que simulam um ambiente real de acordo com a
arquitetura (OLTP, OLAP ou Web) do seu sistema.

Não conheço nenhuma diferença... Com exceção do fato de que há
tunnings que podem ser feitos com os semáforos do kernel em
Linux/FreeBSD que não se conseguem no Windows.

Como eu disse esses conceito *não* existe (é emulado) no Windows.

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

From forum: PostgreSQL - Brasil

Re: CREATE SERVER - what is this?

2009-11-26T02:52:34Z

Le mardi 24 novembre 2009 à 16:45:27, Richard Broersma a écrit :
> I noticed a few new SQL references in the manual:
>
> CREATE SERVER
> CREATE FOREIGN DATA WRAPPER,
> CREATE USER MAPPING
>
> Is this similar to DBI-Link?
>

They appear on the 8.4 release. They were added to support the use of SQL/MED
compliant FOREIGN DATA WRAPPER, SERVER, and USER MAPPING as method to supply
dblink connect parameters. dblink can already use these informations AFAIK.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com

--
Sent via pgsql-sql mailing list (pgsql-sql@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql

From forum: PostgreSQL - sql

Re: specifying a password on the cmd line for db connect

2009-11-26T02:48:17Z

On 2009-11-17, Ashesh Vashi <ashesh.vashi@...> wrote:
> --000e0cd211e054ab9404788a05cf
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Dave,
>
> You can always use the environment variable PGPASSWORD to do that.
> Though - it is not recommended to use for security reason. :(

as long as it's not in the default environment it's better than a
command-line password.

--
Sent via pgsql-general mailing list (pgsql-general@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

From forum: PostgreSQL - general

Re: specifying a password on the cmd line for db connect

2009-11-26T02:46:18Z

On 2009-11-16, Gauthier, Dave <dave.gauthier@...> wrote:
> --_000_482E80323A35A54498B8B70FF2B87980042237CF64azsmsx504amrc_
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> Hi:
>
> Is there a way to require and specify a password at the cmd line for a conn=
> ect? At first glance...

PGPASSWORD=fee psql --username foo ...

><html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
> hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40">

for winders

set PGPASSWORD=fee
psql --username foo ....

--
Sent via pgsql-general mailing list (pgsql-general@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

From forum: PostgreSQL - general