Pessoal, Nessa minha consulta ela trabalha com tabelas que tem quase 1 milhão de registros. O que eu quero saber, é como otimizar essa consulta ou o PostgreSQL.
Essa diferença de tempo de resposta do PostgreSQL em relação ao MySQL é muito grande. PostgreSQL - 7 segundos MySQL - 0.12 segundos 7 segundos não é um tempo aceitável de resposta. Eu entendo a sua imparcialidade, mas não me ajudou a resolver o meu problema. Obrigado. Abraço. Em 22/01/08, [EMAIL PROTECTED] < [EMAIL PROTECTED]> escreveu: > > Send pgbr-geral mailing list submissions to > pgbr-geral@listas.postgresql.org.br > > To subscribe or unsubscribe via the World Wide Web, visit > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of pgbr-geral digest..." > > > Tópicos de Hoje: > > 1. Re: PostgreSQL x MySQL (junior Prado) > 2. Re: PostgreSQL x MySQL ( Pablo Sánchez ) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Jan 2008 07:59:57 -0200 > From: "junior Prado" <[EMAIL PROTECTED]> > Subject: Re: [pgbr-geral] PostgreSQL x MySQL > To: "Comunidade PostgreSQL Brasileira" > <pgbr-geral@listas.postgresql.org.br> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > COMPARAÇÕES ENTRE MYSQL E POSTGRESQL > > > Cobertura do sql > > > Em termos de expressividade as linguagens suportadas pelos dois sistemas > > são bastante equivalentes. > > > Armazenamento e estrutura de dados > > > O MySQL no campo de armazenamento de dados prima principalmente pela > variedade. Fornece aos seus utilizadores a oportunidade de escolher a > forma > de armazenamento que mais se adequa a utilização que irá dar à base de > dados. > > Ambos os sistemas usam as funcionalidades do Sistema Operacional para > organizar os dados em disco. > > O tipo de tabelas por omissão do MySQL guarda os dados sob a forma de > registos seqüenciais de tamanho fixo ou variável ao passo que o PostgreSQL > guarda todos os dados em Slotted Page(ponteiros apontados para registros). > > A primeira abordagem é mais genérica e pode ser usada em qualquer suporte > físico, a segunda tenta tirar o maior partido do suporte físico mais comum > para bases de dados: os discos magnéticos. > > A possibilidade de compressão de alguns dados oferecida pelo MySQL pode > ser > uma mais-valia para ambientes onde os recursos são escassos.(ex. sistemas > embutidos) > > > Indexação > > > Embora ambos os sistemas permitam indexação, o MySQL é um pouco mais > limitado neste aspecto. > > A flexibilidade oferecida pela variedade de storage engines torna-se aqui > algo limitante quando alguns índices apenas estão disponíveis para alguns > tipos de tabelas. > > A funcionalidade de índices sobre parte da chave do MySQL pode ser > simulada > em PostgreSQL com a funcionalidade de índices com uma função sobre os > atributos como chave (substring), ao mesmo tempo que permite funções mais > complexas. > > Embora o MySQL possua um indexador de fulltext bastante flexível, o > PostgreSQL tem dois mecanismos de indexação sobre os quais podem ser > construídos quaisquer índices (em teoria) e onde foram de fato construídos > índices de fulltext, presente nos módulos contribuídos (tsearch2). > > O PostgreSQL não permite associar a organização de uma tabela com a ordem > de > um índice, embora permita uma operação única de ordenação(CLUSTER). > > O MySQL não suporta nada como a indexação parcial do PostgreSQL, poupa > espaço ao impedir que os índices se tornem inúteis devido a estarem > populados com valores comuns e/ou desinteressantes. > > > Processamento e Otimização de queries > > > O otimizador e executor de queries do PostgreSQL são obviamente mais > avançados que os módulos correspondentes no MySQL. > > A simplicidade tanto do planejador como do executor de queries do MySQL > pode > ser explicado pelo fato de este sistema apontar principalmente para o uso > em > páginas web em que as queries nem são complicadas nem incidem numa > quantidade considerável de dados. > > Mais uma vez notamos numa dualidade de critérios sobre as funcionalidades > presentes dependendo do storage engine usado. > > O MySQL permite, no entanto, uma forma mais fácil de dar indicações sobre > como realizar as operações, funcionalidade que no PostgreSQL é bastante > mais > difícil, para algumas dicas até mesmo impossível de conseguir. > > > Transações e controle de concorrência > > > Mais uma vez no MySQL as transações mostram serem uma funcionalidade > presente apenas para algumas escolhas no que diz respeito à forma de > guardar > as tabelas. Será certamente uma pena não haver a possibilidade de se ter > acesso concorrente com algumas garantias de isolamento em tabelas onde se > pode querer usar índices fulltext, por exemplo. > > Esta abordagem mista também da luz a muitos casos especiais que o > programador deve ter cuidado se quiser (ou tiver de) misturar vários > storage > engines. > > Por outro lado ao ter algoritmos menos complicados, ou simplesmente a não > os > ter, de controle e gestão de concorrência, o MySQL pode ganhar na área da > eficiência. > > Um exemplo disto é a execuções da função de agregação count. Enquanto que > devido ao fato de se ter de ler as tuplas da página de forma a determinar > a > sua visibilidade para a transações corrente, no PostgreSQL a melhor forma > de > responder a uma pergunta com essa funções é percorrendo toda a relações, o > que em alguns casos pode ser muito demorado. > > O MySQL com as tabelas MyISAM é perfeitamente capaz de responder a uma > pergunta deste gênero consultando apenas meta-dados sobre a tabela, ou > índices. > > O sistema de controle de transações do PostgreSQL parece ser bastante mais > robusto e consistente. O fato de sua semântica e gestão das tuplas > requerer > manutenção temporária pode ser visto como outra desvantagem das escolhas > tomadas. > > > Suporte para base de dados distribuídas > > > Embora também seja possível obter replicações de bases de dados PostgreSQL > usando os seus logs, não é uma funcionalidade de fácil acesso pelo que > para > todos os efeitos consideramos que o PostgreSQL poderia oferecer um pouco > mais neste aspecto. > > O MySQL fornece uma forma bastante transparente (um storage engine) de > acessar remotamente a outras bases de dados, funcionalidade que está em > falta no PostgreSQL. Mesmo não sendo suporte consagrado para distribuição > da > base de dados uma vez que não mantém o esquema da tabela sincronizado, nem > permite a criação transparente de tabelas em hosts remotos, uma > funcionalidade com bastante utilidade. > > > Conclusões > > > O MySQL: É o mais ágil, pois é otimizado para proporcionar processamento > rápido dos dados e tempo curto de resposta sem exigir muito do hardware. > > Quando Usar o MySQL > > a. Back-end para geração de conteúdo de web sites; > > b. Aplicação envolvendo basicamente consultas e inserção de dados. Sugiro > não usar para aplicações com fortes demandas transacionais, (especialmente > se houverem atualizações concorrentes)! > > c. Empresas como o Yahoo Finance combinam o MySQL (aplicações web) com um > outro banco de dados (retaguarda financeira). > > Flickr também usa MySQL, e são mais de 800 queries simultâneas por > segundo, > entre outras estatísticas surpreendentes. > > > O PostgreSQL: é para aplicações complexas, ou seja, quando envolvem um > grande volume de dados(acima de 5 milhões por dia) ou que tratam > informações > críticas. > > Quando Usar o PostgreSQL > > Aplicações com fortes componentes transacionais. Aplicações que necessitem > de tipos de dados especializados, como Sistemas de Informações Geográficas > (SIG) e repositórios de meta-dados. Projetos baseados em metodologias > Orientadas Objeto - perda de compatibilidade com o padrão ANSI SQL > Aplicações OLAP "light", que não necessitem do nível de sofisticação de um > DataWarehouse. > > > -- > Valter Cezar Prado Junior > Analista TI > > Sem saber como fazer ele fez! > -------------- Próxima Parte ---------- > Um anexo em HTML foi limpo... > URL: > http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20080122/6b5c126b/attachment-0001.htm > > ------------------------------ > > Message: 2 > Date: Tue, 22 Jan 2008 07:59:34 -0300 > From: " Pablo Sánchez " <[EMAIL PROTECTED]> > Subject: Re: [pgbr-geral] PostgreSQL x MySQL > To: "Comunidade PostgreSQL Brasileira" > <pgbr-geral@listas.postgresql.org.br> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Excelente análise, bastante imparcial. Parabéns. > > Em 22/01/08, junior Prado <[EMAIL PROTECTED]> escreveu: > > > > COMPARAÇÕES ENTRE MYSQL E POSTGRESQL > > > > > > Cobertura do sql > > > > > > Em termos de expressividade as linguagens suportadas pelos dois > sistemas > > > > são bastante equivalentes. > > > > > > Armazenamento e estrutura de dados > > > > > > O MySQL no campo de armazenamento de dados prima principalmente pela > > variedade. Fornece aos seus utilizadores a oportunidade de escolher a > forma > > de armazenamento que mais se adequa a utilização que irá dar à base de > > dados. > > > > Ambos os sistemas usam as funcionalidades do Sistema Operacional para > > organizar os dados em disco. > > > > O tipo de tabelas por omissão do MySQL guarda os dados sob a forma de > > registos seqüenciais de tamanho fixo ou variável ao passo que o > PostgreSQL > > guarda todos os dados em Slotted Page(ponteiros apontados para > registros). > > > > A primeira abordagem é mais genérica e pode ser usada em qualquer > suporte > > físico, a segunda tenta tirar o maior partido do suporte físico mais > comum > > para bases de dados: os discos magnéticos. > > > > A possibilidade de compressão de alguns dados oferecida pelo MySQL pode > > ser uma mais-valia para ambientes onde os recursos são escassos.(ex. > > sistemas embutidos) > > > > > > Indexação > > > > > > Embora ambos os sistemas permitam indexação, o MySQL é um pouco mais > > limitado neste aspecto. > > > > A flexibilidade oferecida pela variedade de storage engines torna-se > aqui > > algo limitante quando alguns índices apenas estão disponíveis para > alguns > > tipos de tabelas. > > > > A funcionalidade de índices sobre parte da chave do MySQL pode ser > > simulada em PostgreSQL com a funcionalidade de índices com uma função > sobre > > os atributos como chave (substring), ao mesmo tempo que permite funções > mais > > complexas. > > > > Embora o MySQL possua um indexador de fulltext bastante flexível, o > > PostgreSQL tem dois mecanismos de indexação sobre os quais podem ser > > construídos quaisquer índices (em teoria) e onde foram de fato > construídos > > índices de fulltext, presente nos módulos contribuídos (tsearch2). > > > > O PostgreSQL não permite associar a organização de uma tabela com a > ordem > > de um índice, embora permita uma operação única de ordenação(CLUSTER). > > > > O MySQL não suporta nada como a indexação parcial do PostgreSQL, poupa > > espaço ao impedir que os índices se tornem inúteis devido a estarem > > populados com valores comuns e/ou desinteressantes. > > > > > > Processamento e Otimização de queries > > > > > > O otimizador e executor de queries do PostgreSQL são obviamente mais > > avançados que os módulos correspondentes no MySQL. > > > > A simplicidade tanto do planejador como do executor de queries do MySQL > > pode ser explicado pelo fato de este sistema apontar principalmente para > o > > uso em páginas web em que as queries nem são complicadas nem incidem > numa > > quantidade considerável de dados. > > > > Mais uma vez notamos numa dualidade de critérios sobre as > funcionalidades > > presentes dependendo do storage engine usado. > > > > O MySQL permite, no entanto, uma forma mais fácil de dar indicações > sobre > > como realizar as operações, funcionalidade que no PostgreSQL é bastante > mais > > difícil, para algumas dicas até mesmo impossível de conseguir. > > > > > > Transações e controle de concorrência > > > > > > Mais uma vez no MySQL as transações mostram serem uma funcionalidade > > presente apenas para algumas escolhas no que diz respeito à forma de > guardar > > as tabelas. Será certamente uma pena não haver a possibilidade de se ter > > acesso concorrente com algumas garantias de isolamento em tabelas onde > se > > pode querer usar índices fulltext, por exemplo. > > > > Esta abordagem mista também da luz a muitos casos especiais que o > > programador deve ter cuidado se quiser (ou tiver de) misturar vários > storage > > engines. > > > > Por outro lado ao ter algoritmos menos complicados, ou simplesmente a > não > > os ter, de controle e gestão de concorrência, o MySQL pode ganhar na > área da > > eficiência. > > > > Um exemplo disto é a execuções da função de agregação count. Enquanto > que > > devido ao fato de se ter de ler as tuplas da página de forma a > determinar a > > sua visibilidade para a transações corrente, no PostgreSQL a melhor > forma de > > responder a uma pergunta com essa funções é percorrendo toda a relações, > o > > que em alguns casos pode ser muito demorado. > > > > O MySQL com as tabelas MyISAM é perfeitamente capaz de responder a uma > > pergunta deste gênero consultando apenas meta-dados sobre a tabela, ou > > índices. > > > > O sistema de controle de transações do PostgreSQL parece ser bastante > mais > > robusto e consistente. O fato de sua semântica e gestão das tuplas > requerer > > manutenção temporária pode ser visto como outra desvantagem das escolhas > > tomadas. > > > > > > Suporte para base de dados distribuídas > > > > > > Embora também seja possível obter replicações de bases de dados > > PostgreSQL usando os seus logs, não é uma funcionalidade de fácil acesso > > pelo que para todos os efeitos consideramos que o PostgreSQL poderia > > oferecer um pouco mais neste aspecto. > > > > O MySQL fornece uma forma bastante transparente (um storage engine) de > > acessar remotamente a outras bases de dados, funcionalidade que está em > > falta no PostgreSQL. Mesmo não sendo suporte consagrado para > distribuição da > > base de dados uma vez que não mantém o esquema da tabela sincronizado, > nem > > permite a criação transparente de tabelas em hosts remotos, uma > > funcionalidade com bastante utilidade. > > > > > > Conclusões > > > > > > O MySQL: É o mais ágil, pois é otimizado para proporcionar > processamento > > rápido dos dados e tempo curto de resposta sem exigir muito do hardware. > > > > Quando Usar o MySQL > > > > a. Back-end para geração de conteúdo de web sites; > > > > b. Aplicação envolvendo basicamente consultas e inserção de dados. > Sugiro > > não usar para aplicações com fortes demandas transacionais, > (especialmente > > se houverem atualizações concorrentes)! > > > > c. Empresas como o Yahoo Finance combinam o MySQL (aplicações web) com > um > > outro banco de dados (retaguarda financeira). > > > > Flickr também usa MySQL, e são mais de 800 queries simultâneas por > > segundo, entre outras estatísticas surpreendentes. > > > > > > O PostgreSQL: é para aplicações complexas, ou seja, quando envolvem um > > grande volume de dados(acima de 5 milhões por dia) ou que tratam > informações > > críticas. > > > > Quando Usar o PostgreSQL > > > > Aplicações com fortes componentes transacionais. Aplicações que > necessitem > > de tipos de dados especializados, como Sistemas de Informações > Geográficas > > (SIG) e repositórios de meta-dados. Projetos baseados em metodologias > > Orientadas Objeto - perda de compatibilidade com o padrão ANSI SQL > > Aplicações OLAP "light", que não necessitem do nível de sofisticação de > um > > DataWarehouse. > > > > > > -- > > Valter Cezar Prado Junior > > Analista TI > > > > Sem saber como fazer ele fez! > > _______________________________________________ > > pgbr-geral mailing list > > pgbr-geral@listas.postgresql.org.br > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > > > -------------- Próxima Parte ---------- > Um anexo em HTML foi limpo... > URL: > http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20080122/b0154899/attachment.htm > > ------------------------------ > > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > Fim da Digest pgbr-geral, volume 11, assunto 53 > *********************************************** > -- Patrick Espake e-mail: [EMAIL PROTECTED] site: www.patrickespake.com
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
