Ola Matheus Valeu pela dica da view pg_stats coluna correlation.
Não importa se é vinculada a tabela a métrica, tendo no SGBD é o que importa. []'s Em 30 de agosto de 2014 14:12, Matheus de Oliveira < [email protected]> escreveu: > > 2014-08-29 19:10 GMT-03:00 Wiliam Balan <[email protected]>: > > Se as linhas de uma tabela no disco são classificadas em aproximadamente a >> mesma ordem que as chaves de índice, o banco de dados irá realizar um >> número mínimo de I/Os em cima da tabela para ler a tabela inteira através >> do índice. Do contrário,vai ser feito um número maior de I/Os em cima da >> tabela >> >> > Bem explicado. Só complementando, não é somente isso. Se considerarmos > ainda que a leitura da tabela cabe em cache, então o número de I/Os > necessários é o mesmo, independente do "cluster factor" (o termo não é > comum para o PostgreSQL, mas "entendível"). Agora, outro problema com esse > fator alto (tabela desorganizada) é que o número de operações aleatórias > (random I/O) é muito maior do que as sequenciais (seq I/O), e é sabido que > operações aleatórias nos discos são mais lentas que sequenciais (para SSD é > bem menos, mas creio que seq ainda seja um pouco -- só um pouco -- melhor > por causa do "pre-fetch"). E sim, o PostgreSQL utiliza de tal informação > para decidir entre o uso de um índice ou ou não (ou até uso do índice + > bitmap para diminuir o acesso aleatório). > > > >> vejam esse exemplo: >> >> SQL> create table organized >> 2 as >> 3 select x.* >> 4 from (select * from stage >> order by object_name) x >> 5 / >> Table created. >> >> SQL> create table disorganized >> 2 as >> 3 select x.* >> 4 from (select * from stage >> order by dbms_random.random) x >> 5 / >> Table created. >> >> > > Só para termos o exemplo em PostgreSQL e o pessoal poder entender/testar > neste: > > CREATE TABLE stage AS /* uma tabela de exemplo */ > SELECT i, md5(random()::text) AS object_name) > FROM generate_series(1, 1000000) i; > CREATE TABLE organized AS (SELECT * FROM stage ORDER BY object_name); > CREATE TABLE disorganized AS (SELECT * FROM stage ORDER BY random()); > > E creio que esteja considerando um índice em object_name: > > CREATE INDEX ON organized (object_name); > CREATE INDEX ON disorganized (object_name); > > > >> Nesse caso a tabela chamada DISORGANIZED vai ter um INDEX CLUSTERING >> FACTOR muito alto, pois os dados estao totalmente desordenados. Um bom >> clustering factor é igual ou próximo ao número de blocos de uma tabela. Um >> clustering factor ruim é é igual ou próximo ao número de linhas de uma >> tabela. >> >> >> No postgreSQL algum sabe se tem essa estatistica? >> > > > Sim. A estatística está presente no PostgreSQL, mas não é por índice, mas > sim para cada coluna da tabela (basta pegar as colunas do índice então). > Para conferir esse valor, basta consultar a coluna correlation da view > pg_stats: > > SELECT tablename, correlation > FROM pg_stats > WHERE tablename IN ('organized', 'disorganized') > AND attname = 'object_name'; > > Essa coluna quando -1 indica totalmente ordenada em ordem decrescente, 1 > totalmente ordenada em ordem crescente, e valores decimais entre -1 e 1 é o > fator (sendo negativo decrescente e positivo crescente). Detalhes sobre a > pg_stats em [1]. > > [1] http://www.postgresql.org/docs/current/static/view-pg-stats.html > > Atenciosamente, > -- > Matheus de Oliveira > Analista de Banco de Dados > Dextra Sistemas - MPS.Br nível F! > www.dextra.com.br/postgres > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
