date:20101116

Re: [pgbr-geral] RES: Indice composto

2010-11-16 Thread Euler Taveira de Oliveira

Moisés Caribé Ribeiro escreveu:
> - campos nulos não utilizam índices
> 
Ugh? É claro que posso ter consultas WHERE foo IS NULL que utilizam um índice.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Indice composto

2010-11-16 Thread Marcal Hokama


___
> From: betol...@gmail.com
> Date: Tue, 16 Nov 2010 11:04:37 -0300
> To: pgbr-geral@listas.postgresql.org.br
> Subject: [pgbr-geral] RES: Indice composto
>
> Mas assim: eu também vou buscar pelos campos "descricao,
> data_inicio_agenda, data_fim_agenda" além do titulo.
> Saco fora os indices?
>
> valeu

Fiquei com uma dúvida, a sua busca vai ter na cláusula WHERE:

1) titulo E descricao E data_inicio_agenda E data_fim_agenda

ou

2) combinações das colunas titulo, descricao, data_inicio_agenda, 
data_fim_agenda (às vezes algumas delas não aparecem).

???

Marçal de Lima Hokama

e-mail: mhok...@hotmail.com
http://twitter.com/mhokama
  
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ajuda com disparador

2010-11-16 Thread Eloi Ribeiro

2010/11/16 Osvaldo Kussama 

> Em 15 de novembro de 2010 14:38, Eloi Ribeiro 
> escreveu:
> > Olá à lista,
> > Queria fazer um disparador sobre uma tabela com dois campos do
> > tipo 'Geometry' (geom_23030 e geom_4258) cada um com um sistema de
> > coordenadas diferente.
> > A ideia era que o disparador actualiza-se o segundo campo sempre que
> > houvesse um INSERT ou UPDATE no primeiro campo e assim tivessem sempre a
> > mesma geometria mas cada um dos campos com o seu respectivo sistemas de
> > coordenadas.
> > Devido à minha falta de experiência em plpgsql eu não sei como fazer para
> > que o disparador reconheça qual a geometria mais recente e proceder com
> > a actualização da mais antiga. Como tenho feito, actualiza por ordem de
> como
> > está indicado no disparador sem ter em conta a antiguidade. Deveria
> > adicionar dois novos campos com Time Stamp de cada uma das geometrias
> para
> > conseguir o meu objectivo?
> > Estou a usar algumas das funções disponibilizadas pela extensão PostGIS.
> > Isto foi o que consegui fazer:
> > --SELECT DropGeometryColumn('sch_temp','teste','geom_23030');
> > --SELECT DropGeometryColumn('sch_temp','teste','geom_4258');
> > --DROP TABLE sch_temp.teste;
> > CREATE TABLE sch_temp.teste (gid serial primary key, longitude double
> > precision);
> > SELECT AddGeometrycolumn
> > ('sch_temp','teste','geom_23030',23030,'LINESTRING',2);
> > SELECT AddGeometrycolumn
> > ('sch_temp','teste','geom_4258',4258,'LINESTRING',2);
> > CREATE OR REPLACE FUNCTION funcao_teste() RETURNS trigger AS
> > $$
> > BEGIN
> > -- Se o campo geom_4258 tem um novo INSERT ou UPDATE, entao actualiza
> > geom_23030.
> > NEW.geom_23030 = ST_Transform((NEW.geom_4258), 23030);
> >
> > -- Se o campo geom_23030 tem um novo INSERT ou UPDATE, entao actualiza
> > geom_4258.
> > NEW.geom_4258 = ST_Transform((NEW.geom_23030), 4258);
> > -- Calcula/actualiza a longitude da geometria.
> > NEW.longitude  = ST_Length(NEW.geom_23030);
> > RETURN NEW;
> > END;
> > $$ LANGUAGE plpgsql;
> > DROP TRIGGER IF EXISTS funcao_teste ON sch_temp.teste;
> > CREATE TRIGGER funcao_teste BEFORE INSERT OR UPDATE ON sch_temp.teste FOR
> > EACH ROW EXECUTE PROCEDURE funcao_teste();
> > INSERT INTO sch_temp.teste(geom_23030)
> > VALUES(ST_GeomFromText('SRID=23030;LINESTRING(232400 4548000,700882
> > 4548000)'));
> > INSERT INTO sch_temp.teste(geom_4258) VALUES
> > (ST_GeomFromText('SRID=4258;LINESTRING(-6 38,-1 38)'));
> > UPDATE sch_temp.teste SET geom_4258 =
> > ST_GeomFromText('SRID=4258;LINESTRING(-5 37,-1 37)') WHERE gid = 2;
> > SELECT gid, longitude, ST_AsText(geom_23030), ST_AsText(geom_4258) FROM
> > sch_temp.teste;
> > Obrigado. Cumprimentos,
> >
>
>
> Pelo que entendi você deve:
> - verificar qual é a operação (TG_OP);
> - se for INSERT, verificar em NEW qual foi a informada e calcular a
> outra, colocando o resultado em NEW;
> - se for UPDATE, verificar qual foi alterada e calcular a que não foi
> alterada, colocando o resultado em NEW;
>
> CREATE OR REPLACE FUNCTION funcao_teste() RETURNS trigger AS
> $$
> BEGIN
> IF (TG_OP = 'INSERT') THEN
>IF (NEW.geom_4258 IS NOT NULL) THEN
>-- Se o campo geom_4258 tem um novo INSERT, entao actualiza
> geom_23030.
> NEW.geom_23030 = ST_Transform((NEW.geom_4258), 23030);
> ELSE
>-- Se o campo geom_23030 tem um novo INSERT, entao actualiza
> geom_4258.
> NEW.geom_4258 = ST_Transform((NEW.geom_23030), 4258);
> END IF;
> ELSE
>IF (TG_OP = 'UPDATE') THEN
>IF (NEW.geom_4258 IS NOT NULL) THEN
> NEW.geom_23030 = ST_Transform((NEW.geom_4258),
> 23030);
> ELSE
>IF (OLD.geom_23030 IS NOT NULL) THEN
> NEW.geom_4258 =
> ST_Transform((NEW.geom_23030), 4258);
> END IF;
>END IF;
> END IF;
> RETURN NEW;
> END;
> $$ LANGUAGE plpgsql;
>
> ou algo nesta linha.
>
> Osvaldo
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Obrigado Osvaldo, era isso mesmo que queria fazer.
Apenas nao funciona o ultimo UPDATE.
Simplificando o exemplo anterior:

--DROP TABLE sch_temp.teste;
CREATE TABLE sch_temp.teste (id serial primary key, x int, x100 int);

CREATE OR REPLACE FUNCTION funcao_teste() RETURNS trigger AS
$$
BEGIN
IF (TG_OP = 'INSERT') THEN
   IF (NEW.x IS NOT NULL) THEN
   NEW.x100 = NEW.x*100;
   ELSE
   NEW.x = NEW.x100/100;
   END IF;
ELSE
   IF (TG_OP = 'UPDATE') THEN
   IF (NEW.x IS NOT NULL) THEN
   NEW.x100 = NEW.x*100;
   ELSE
IF (OLD.x100 IS NOT NULL) THEN
   NEW.x = NEW.x/100;
END IF;
   END IF;
END IF;
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;

DROP TRIGGER IF EXISTS funcao_teste ON sch_temp.teste;
CR

[pgbr-geral] RES: Indice composto

2010-11-16 Thread Beto Lima

Na clausula where vai ser um ou outro.
ex: where titulo ilike '%valor%'

ou data_inicio_agenda ilike '%valor%'

Não vou unir os valores pra buscar depois, é um ou outro.
A busca funciona conforme digita no campo, no evento keyup com ajax.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Indice composto

2010-11-16 Thread Fábio Telles Rodriguez

Então crie índices individuais para cada campo. Depois verifique se os seus
índices estão sendo realmente utilizados.

2010/11/16 Beto Lima 

> Na clausula where vai ser um ou outro.
> ex: where titulo ilike '%valor%'
>
> ou data_inicio_agenda ilike '%valor%'
>
> Não vou unir os valores pra buscar depois, é um ou outro.
> A busca funciona conforme digita no campo, no evento keyup com ajax.
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>


-- 
blog: http://www.midstorm.org/~telles/
e-mail / jabber: fabio.tel...@gmail.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ajuda com disparador

2010-11-16 Thread Osvaldo Kussama

Em 16 de novembro de 2010 14:33, Eloi Ribeiro  escreveu:
>
> Obrigado Osvaldo, era isso mesmo que queria fazer.
> Apenas nao funciona o ultimo UPDATE.
> Simplificando o exemplo anterior:
> --DROP TABLE sch_temp.teste;
> CREATE TABLE sch_temp.teste (id serial primary key, x int, x100 int);
> CREATE OR REPLACE FUNCTION funcao_teste() RETURNS trigger AS
> $$
> BEGIN
> IF (TG_OP = 'INSERT') THEN
>        IF (NEW.x IS NOT NULL) THEN
>                NEW.x100 = NEW.x*100;
>        ELSE
>                NEW.x = NEW.x100/100;
>        END IF;
> ELSE
>        IF (TG_OP = 'UPDATE') THEN
>                IF (NEW.x IS NOT NULL) THEN
>                        NEW.x100 = NEW.x*100;
>                ELSE
>        IF (OLD.x100 IS NOT NULL) THEN
>       NEW.x = NEW.x/100;
> END IF;
>                END IF;
>         END IF;
> END IF;
> RETURN NEW;
> END;
> $$ LANGUAGE plpgsql;
> DROP TRIGGER IF EXISTS funcao_teste ON sch_temp.teste;
> CREATE TRIGGER funcao_teste BEFORE INSERT OR UPDATE ON sch_temp.teste FOR
> EACH ROW EXECUTE PROCEDURE funcao_teste();
> INSERT INTO sch_temp.teste(x) VALUES(1);
> INSERT INTO sch_temp.teste(x100) VALUES (200);
> SELECT * FROM sch_temp.teste;
> 1;1;100
> 2;2;200
> Os INSERTS funcionam na perfeição.
> UPDATE sch_temp.teste SET x = 3 WHERE x = 2;
> SELECT * FROM sch_temp.teste;
> 1;1;100
> 2;3;300
> O primeiro UPDATE também.
> UPDATE sch_temp.teste SET x100 = 200 WHERE x = 3;
> SELECT * FROM sch_temp.teste;
> 1;1;100
> 2;3;300
> Excepto este ultimo que não dispara. Porque?
> Aqui o resultado deveria ser:
> 1;1;100
> 2;2;200
> Obrigado por toda a ajuda.
> Eloi


Creio que você precisa rever quais testes devem ser feitos.
Talvez:
IF (OLD.x100 IS NOT NULL) THEN
  NEW.x = NEW.x/100;
END IF;
deva, na realidade ser:
IF (NEW.x100 IS NOT NULL) THEN
  NEW.x = NEW.x/100;
END IF;

Eu não entendi muito bem se sempre que atualizar uma coordenada a
outra deve ser automaticamente modificada ou se isto depende de alguma
outra informação ou pré-existência de dados.

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

Re: [pgbr-geral] ajuda com disparador

2010-11-16 Thread Eloi Ribeiro

On Tue, Nov 16, 2010 at 19:34, Osvaldo Kussama wrote:

> Em 16 de novembro de 2010 14:33, Eloi Ribeiro 
> escreveu:
> >
> > Obrigado Osvaldo, era isso mesmo que queria fazer.
> > Apenas nao funciona o ultimo UPDATE.
> > Simplificando o exemplo anterior:
> > --DROP TABLE sch_temp.teste;
> > CREATE TABLE sch_temp.teste (id serial primary key, x int, x100 int);
> > CREATE OR REPLACE FUNCTION funcao_teste() RETURNS trigger AS
> > $$
> > BEGIN
> > IF (TG_OP = 'INSERT') THEN
> >IF (NEW.x IS NOT NULL) THEN
> >NEW.x100 = NEW.x*100;
> >ELSE
> >NEW.x = NEW.x100/100;
> >END IF;
> > ELSE
> >IF (TG_OP = 'UPDATE') THEN
> >IF (NEW.x IS NOT NULL) THEN
> >NEW.x100 = NEW.x*100;
> >ELSE
> >IF (OLD.x100 IS NOT NULL) THEN
> >   NEW.x = NEW.x/100;
> > END IF;
> >END IF;
> > END IF;
> > END IF;
> > RETURN NEW;
> > END;
> > $$ LANGUAGE plpgsql;
> > DROP TRIGGER IF EXISTS funcao_teste ON sch_temp.teste;
> > CREATE TRIGGER funcao_teste BEFORE INSERT OR UPDATE ON sch_temp.teste FOR
> > EACH ROW EXECUTE PROCEDURE funcao_teste();
> > INSERT INTO sch_temp.teste(x) VALUES(1);
> > INSERT INTO sch_temp.teste(x100) VALUES (200);
> > SELECT * FROM sch_temp.teste;
> > 1;1;100
> > 2;2;200
> > Os INSERTS funcionam na perfeição.
> > UPDATE sch_temp.teste SET x = 3 WHERE x = 2;
> > SELECT * FROM sch_temp.teste;
> > 1;1;100
> > 2;3;300
> > O primeiro UPDATE também.
> > UPDATE sch_temp.teste SET x100 = 200 WHERE x = 3;
> > SELECT * FROM sch_temp.teste;
> > 1;1;100
> > 2;3;300
> > Excepto este ultimo que não dispara. Porque?
> > Aqui o resultado deveria ser:
> > 1;1;100
> > 2;2;200
> > Obrigado por toda a ajuda.
> > Eloi
>
>
> Creio que você precisa rever quais testes devem ser feitos.
> Talvez:
> IF (OLD.x100 IS NOT NULL) THEN
>  NEW.x = NEW.x/100;
> END IF;
> deva, na realidade ser:
> IF (NEW.x100 IS NOT NULL) THEN
>   NEW.x = NEW.x/100;
> END IF;
>
> Eu não entendi muito bem se sempre que atualizar uma coordenada a
> outra deve ser automaticamente modificada ou se isto depende de alguma
> outra informação ou pré-existência de dados.
>
> Osvaldo
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Com esta ultima alteração os resultados são os mesmos.
Nao existe nenhuma outra dependência, ao actualizar  uma coordenada a
outra deve ser automaticamente modificada.

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

Re: [pgbr-geral] ajuda com disparador

2010-11-16 Thread Osvaldo Kussama

Em 16 de novembro de 2010 17:22, Eloi Ribeiro  escreveu:
>
> Com esta ultima alteração os resultados são os mesmos.
> Nao existe nenhuma outra dependência, ao actualizar  uma coordenada a
> outra deve ser automaticamente modificada.
> Eloi


IF (NEW.x100 IS NOT NULL) THEN
 NEW.x = NEW.x100/100;
END IF;

É isso? Calcular um novo x em função de x100?



CREATE OR REPLACE FUNCTION funcao_teste() RETURNS trigger AS
$$
BEGIN
IF (TG_OP = 'INSERT') THEN
IF (NEW.x IS NOT NULL) THEN
NEW.x100 = NEW.x*100;
ELSE
NEW.x = NEW.x100/100;
END IF;
ELSE
IF (TG_OP = 'UPDATE') THEN
IF (NEW.x IS NOT NULL) THEN
NEW.x100 = NEW.x*100;
ELSE
IF (NEW.x100 IS NOT NULL) THEN
NEW.x = NEW.x100/100;
END IF;
END IF;
END IF;
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;


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

Re: [pgbr-geral] ajuda com disparador

2010-11-16 Thread Eloi Ribeiro

On Tue, Nov 16, 2010 at 21:02, Osvaldo Kussama wrote:

> Em 16 de novembro de 2010 17:22, Eloi Ribeiro 
> escreveu:
> >
> > Com esta ultima alteração os resultados são os mesmos.
> > Nao existe nenhuma outra dependência, ao actualizar  uma coordenada a
> > outra deve ser automaticamente modificada.
> > Eloi
>
>
> IF (NEW.x100 IS NOT NULL) THEN
>  NEW.x = NEW.x100/100;
> END IF;
>
> É isso? Calcular um novo x em função de x100?
>
> 
>
> CREATE OR REPLACE FUNCTION funcao_teste() RETURNS trigger AS
> $$
> BEGIN
> IF (TG_OP = 'INSERT') THEN
>IF (NEW.x IS NOT NULL) THEN
>NEW.x100 = NEW.x*100;
>ELSE
>NEW.x = NEW.x100/100;
>END IF;
> ELSE
>IF (TG_OP = 'UPDATE') THEN
>IF (NEW.x IS NOT NULL) THEN
>NEW.x100 = NEW.x*100;
>ELSE
> IF (NEW.x100 IS NOT NULL) THEN
> NEW.x = NEW.x100/100;
> END IF;
>END IF;
>END IF;
> END IF;
> RETURN NEW;
> END;
> $$ LANGUAGE plpgsql;
>
>
> Osvaldo
> __
>

Tens razão tinha ai um erro, mas mesmo assim com ultimo UPDATE (ver mais a
baixo) não se obtém o resultado esperado.
Não entendo o que está mal...

INSERT INTO sch_temp.teste(x) VALUES(1);
INSERT INTO sch_temp.teste(x100) VALUES (200);
SELECT * FROM sch_temp.teste;
1;1;100
2;2;200
Resultado esperado.

UPDATE sch_temp.teste SET x = 3 WHERE x = 2;
SELECT * FROM sch_temp.teste;
1;1;100
2;3;300
Resultado esperado.

UPDATE sch_temp.teste SET x100 = 200 WHERE x = 3;
SELECT * FROM sch_temp.teste;
1;1;100
2;3;300
Resultado NÃO esperado. Deveria ser:
1;1;100
2;2;200


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

[pgbr-geral] RES: Indice composto

2010-11-16 Thread Beto Lima

"Então crie índices individuais para cada campo. Depois verifique se os seus
índices estão sendo realmente utilizados."

Ok obrigado, mas como posso verificar depois isso?
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: Indice composto

2010-11-16 Thread Marcal Hokama



> From: betol...@gmail.com
> Date: Tue, 16 Nov 2010 18:28:58 -0300
> To: pgbr-geral@listas.postgresql.org.br
> Subject: [pgbr-geral] RES: Indice composto
>
> "Então crie índices individuais para cada campo. Depois verifique se os seus
> índices estão sendo realmente utilizados."
>
> Ok obrigado, mas como posso verificar depois isso?
>
Olá Beto,
 
Analisando o plano de execução de cada consulta com o comando EXPLAIN
 
Mais detalhes sobre o comando em 
http://www.postgresql.org/docs/9.0/interactive/using-explain.html
 
 
Marçal de Lima Hokama
-
e-mail:mhok...@hotmail.com
http://twitter.com/mhokama
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ajuda com disparador

2010-11-16 Thread Osvaldo Kussama

O teste está errado. o campo não informado não contém NULL. Teste se é
igual ao OLD.

Veja:
bdteste=# CREATE TEMP TABLE teste (id serial primary key, x int, x100 int);
NOTICE:  CREATE TABLE will create implicit sequence "teste_id_seq" for
serial column "teste.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"teste_pkey" for table "teste"
CREATE TABLE
bdteste=#
bdteste=# CREATE OR REPLACE FUNCTION funcao_teste() RETURNS trigger AS
bdteste-# $$
bdteste$# BEGIN
bdteste$# RAISE NOTICE '% - id: % - x: % - x100: %', TG_OP, NEW.id,
NEW.x, NEW.x100;
bdteste$# IF (TG_OP = 'INSERT') THEN
bdteste$#IF (NEW.x IS NOT NULL) THEN
bdteste$#NEW.x100 = NEW.x*100;
bdteste$#ELSE
bdteste$#NEW.x = NEW.x100/100;
bdteste$#END IF;
bdteste$# ELSE
bdteste$#IF (TG_OP = 'UPDATE') THEN
bdteste$#IF (NEW.x <> OLD.x) THEN
bdteste$#NEW.x100 = NEW.x*100;
bdteste$#ELSE
bdteste$#IF (NEW.x100 <> OLD.x100) THEN
bdteste$#NEW.x = NEW.x100/100;
bdteste$#END IF;
bdteste$#END IF;
bdteste$#END IF;
bdteste$# END IF;
bdteste$# RETURN NEW;
bdteste$# END;
bdteste$# $$ LANGUAGE plpgsql;
CREATE FUNCTION
bdteste=#
bdteste=# CREATE TRIGGER funcao_teste BEFORE INSERT OR UPDATE ON teste
FOR EACH ROW EXECUTE PROCEDURE funcao_teste();
CREATE TRIGGER
bdteste=#
bdteste=# INSERT INTO teste(x) VALUES(1);
NOTICE:  INSERT - id: 1 - x: 1 - x100: 
INSERT 0 1
bdteste=# INSERT INTO teste(x100) VALUES (200);
NOTICE:  INSERT - id: 2 - x:  - x100: 200
INSERT 0 1
bdteste=# SELECT * FROM teste;
 id | x | x100
+---+--
  1 | 1 |  100
  2 | 2 |  200
(2 rows)

bdteste=#
bdteste=# UPDATE teste SET x = 3 WHERE x = 2;
NOTICE:  UPDATE - id: 2 - x: 3 - x100: 200
UPDATE 1
bdteste=# SELECT * FROM teste;
 id | x | x100
+---+--
  1 | 1 |  100
  2 | 3 |  300
(2 rows)

bdteste=#
bdteste=# UPDATE teste SET x100 = 200 WHERE x = 3;
NOTICE:  UPDATE - id: 2 - x: 3 - x100: 200
UPDATE 1
bdteste=# SELECT * FROM teste;
 id | x | x100
+---+--
  1 | 1 |  100
  2 | 2 |  200
(2 rows)

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

Re: [pgbr-geral] RES: Indice composto

2010-11-16 Thread Marcal Hokama


___
> From: betol...@gmail.com
> Date: Tue, 16 Nov 2010 14:10:24 -0300
> To: pgbr-geral@listas.postgresql.org.br
> Subject: [pgbr-geral] RES: Indice composto
>
> Na clausula where vai ser um ou outro.
> ex: where titulo ilike '%valor%'
>
> ou data_inicio_agenda ilike '%valor%'
>
> Não vou unir os valores pra buscar depois, é um ou outro.
> A busca funciona conforme digita no campo, no evento keyup com ajax.
>
Olá Beto,
 
Agora que vi a tua consulta, vai ter um problema: o ilike com o texto de busca 
começando com '%'. Assim não vai usar índices.
 
Mais em http://www.postgresql.org/docs/9.0/interactive/indexes-types.html
 
Marçal de Lima Hokama
-
e-mail: mhok...@hotmail.com
http://twitter.com/mhokama
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Desenvolvimento -> Produção

2010-11-16 Thread Eden Cardim

> "Roberto" == Roberto Mello  writes:

Roberto> A menos que seu banco de dados não tenha nenhuma chave
Roberto> estrangeira ou restrição, e se você não quiser dados
Roberto> repetidos, vai ter que usar um pouco mais de inteligência
Roberto> no seu processo se quiser fazer uma cópia incremental
Roberto> assim. Só com COPY direto não vai dar, a não ser que você
Roberto> apague tudo do de produção a cada nova rodada.

Roberto> Provavelmente um programa que, sabendo dos nomes de todas
Roberto> as tabelas, e sabendo identificar os últimos registros,
Roberto> leiam e enviem para o de produção.

Depende bastante da modelagem, se você fizer uma abordagem temporal, um
COPY serve. Uma forma simples para ilustrar o conceito é associar um
campo representando a data de criação de cada registro, a data passa a
fazer parte da chave primária e você passa a usar sempre usar INSERT
invés de UPDATE no banco de desenvolvimento. Para atualizar o banco de
produção, basta copiar todos os registros criados após a data da última
atualização do banco de produção, que você consegue obter com um

SELECT max(data) FROM tabela_prod;

Isso é claro, vai resultar numa explosão de registros e tabelas bastante
volumosas. Pra resolver isso, você pode particionar a tabela por data,
caso o espaço não seja problema. Outra alternativa é usar uma abordagem
de arquivo morto pra apagar os registros que não sejam os mais recentes
periodicamente, algo como:

DELETE FROM tabela_prod
  USING (SELECT MAX(data) AS data,
id
   FROM tabela_prod
  GROUP BY id) recent
  WHERE tabela_prod.id= recent.id
AND tabela_prod.data != recent.data;

Que deve rodar num tempo aceitável sem fazer lock nos registros mais
recentes. Claro que acrescentar um campo data em todas as tabelas tem
implicações de complexidade, a depender da modelagem. Pode ser que fique
complexo demais e valha a pena usar outra abordagem.

-- 
 Eden CardimNeed help with your perl Catalyst or DBIx::Class 
project?
   Software Engineer   http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.Want a managed development or deployment 
platform?
http://blog.edencardim.com http://www.shadowcat.co.uk/servers/

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

Re: [pgbr-geral] RES: Indice composto

Re: [pgbr-geral] RES: Indice composto

Re: [pgbr-geral] ajuda com disparador

[pgbr-geral] RES: Indice composto

Re: [pgbr-geral] RES: Indice composto

Re: [pgbr-geral] ajuda com disparador

Re: [pgbr-geral] ajuda com disparador

Re: [pgbr-geral] ajuda com disparador

Re: [pgbr-geral] ajuda com disparador

[pgbr-geral] RES: Indice composto

Re: [pgbr-geral] RES: Indice composto

Re: [pgbr-geral] ajuda com disparador

Re: [pgbr-geral] RES: Indice composto

Re: [pgbr-geral] Desenvolvimento -> Produção

14 matches

Site Navigation

Mail list logo

Footer information