doutorado e me convide para a banca.
Atenciosamente,
Mozart Hasse
Date: Mon, 27 Jun 2011 19:38:54 -0300
From: Fábio Telles Rodriguez fabio.tel...@gmail.com
Subject: [pgbr-geral] Avaliando a ordem de colunas em índices
compostos
To: Comunidade PostgreSQL Brasileira
pgbr-geral
observei dessas empacadas me faz acreditar que a organização de
tabelas e índices que indiquei é uma forma de
melhorar (e muito) o desempenho do banco de dados. Se não querem nem
analisar por causa da fonte, só lamento.
Mozart Hasse
___
pgbr-geral mailing
a tabela inteira, o que pode ser
uma diferença de vida ou morte do sistema se estivermos falando de uma
tabela com milhões de registros.
Atenciosamente,
Mozart Hasse
Date: Thu, 9 Jun 2011 09:37:52 -0400
From: izana souza torres izanator...@gmail.com
Subject: [pgbr-geral] - Dúvida sobre índice
LEFT
JOINs (que o elefantinho sofre para resolver), não há mais COALESCEs (que
atrapalham a vida do elefantinho) e não há mais ORs/IS NULLs (desgraça para
qualquer servidor SQL).
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral
Oi Monica,
Seguindo nas suas razoáveis premissas:
A tabela history possui em média *87 milhões* de registros.
É uma tabela que sofre muito insert/update/delete.
Faço analyze e reindexação semanalmente.
Tem como fazer com mais frequência, como por exemplo diariamente? Pelo
volume de
- Original Message -
From: pgbr-geral-requ...@listas.postgresql.org.br
To: pgbr-geral@listas.postgresql.org.br
Sent: Monday, June 21, 2010 4:34 PM
Subject: Digest pgbr-geral, volume 40, assunto 28
Send pgbr-geral mailing list submissions to
pgbr-geral@listas.postgresql.org.br
To
WHERE NOT EXISTS
3. Consulta original trocando OUTER por INNER no segundo LEFT e trocando o
primeiro LEFT por um WHERE NOT EXISTS
4. Consulta original sem OUTER nem INNER, e na cláusula WHERE você coloca
um
NOT EXISTS para o primeiro LEFT e outro NOT EXISTS para o segundo
Mozart Hasse
exposto acima.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
aplicam.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Mateus,
Cuidado ao montar as combinações, há repetições na sua consulta. Faltou
também NOT EXISTS nas tabelas que não sofreram INNER JOIN:
-- com B sem C
SELECT campoA, campoB, null as c
FROM a INNER JOIN b ON (a.id= b.id)
WHERE NOT EXISTS (SELECT 1 FROM c WHERE a.id= c.id)
UNION all
-- sem
a tabela principal sequencialmente. É
exatamente essa habilidade de escolher índices pelo volume da tabela filha
que pode tornar a consulta infinitamente mais rápida.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral
OUTER JOIN está virando
lenda por aqui, praticamente ninguém mais usa.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Olá Fabrízio,
From: Fabrízio de Royes Mello fabriziome...@gmail.com
Em 4 de maio de 2010 22:01, Mozart Hasse mozart.ha...@usa.net escreveu:
Não pude deixar de ver esse comentário sobre entupir as tabelas de
índices
e gostaria de saber exatamente o porque disso e trocar alguma idéia...
É
, mantendo
assim suas tabelas de movimentação pequenas e seu esforço de manutenção bem
grande. É horrível de criar e manter, porém deixa o desempenho num patamar
aceitável.
Boa sorte,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral
'),
position(',' in encode(cstring_send(tidout(ctid)),'escape'))+1,
length(rtrim(encode(cstring_send(tidout(ctid)),'escape'))) - position(',' in
encode(cstring_send(tidout(ctid)),'escape'))-1 )
as int) )
% 10=1
Atenciosamente,
Mozart Hasse
___
pgbr-geral
executando isso:
ctid é um identificador único do registro dentro da tabela, composto por 2
números. O que o fragmento que passei faz é transformar os dois num número
único e tirar o resto da divisão para ter uma distribuição meio
aleatória.
Atenciosamente,
Mozart Hasse
primo no lugar do 199
que seja mais próximo do número de registros por bloco da tabela desejada.
Atenciosamente,
Mozart Hasse
From: Jose Luis Ramos jose.ramos.caj...@gmail.com
Preciso fazer uma funçaõ que, para cada tabela do banco com esse prefixo
(cdrger*), eu leia um registro, grave de alguma
Dickson,
Em 4 de março de 2010 20:13, Mozart Hasse mozart.ha...@usa.net escreveu:
Ah, questão de prática.
-...
cuidar dos malditos 40% sem PK artificial em bases muito menores.
...
Mozart, apenas por curiosidade, essas chaves artificiais são
sequences?
Não, normalmente são apenas
+1 (Falou e disse!)
From: Wolak Sistemas - Fabiano Machado Dias
fabi...@wolaksistemas.com.br
Subject: Re: [pgbr-geral] Usando CPF/CNPJ como PK
Use uma pk artificial e seja feliz. Fuja de pks compostas, elas ainda vao te
dar uma bela dor de cabeca.
Abraco
Ah, questão de prática.
Tenho 900 tabelas para brincar e de proporção deve dar uns 60% com PK
artifical contra 40% sem.
Realmente base com 150GB eu não tenho, mas no meu caso a dor de cabeça é
cuidar dos malditos 40% sem PK artificial em bases muito menores.
Atenciosamente,
Mozart Hasse
From
que dá para fazer.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
lógica mais orientada a conjuntos, pode ser
possível identificar quais comandos geram teu gargalo e aí otimizar mais
este processo.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https
testou,
só posso concluir que estou perdendo meu tempo.
Desisto.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
trecho)
Depende da aplicação. Pelo visto nos últimos 15 anos vivemos em mundos
distintos,
com colegas distintos e requisitos mais distintos ainda.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https
, e não o
uso das chaves seriais, que não tem nada a ver com isso.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Leandro,
Na verdade, chave serial é contradição em termos, porque se é serial
não vai garantir unicidade.
Sim, mas para achar o registro e fazer JOINs, é o que há em termos de
praticidade e desempenho, especialmente se você quiser usar a chave para
identificar alterações concorrentes sobre o
citados cláusula WHERE
- crie mais índices contendo todos os campos citados na consulta para cada
tabela, de preferência em todas as ordens possíveis
- mande o EXPLAIN da consulta após criar essa tralha toda, se ainda precisar
de ajuda
Atenciosamente,
Mozart Hasse
satisfatório. A mesma máquina, rodando Linux, me foi até 10 vezes
melhor. Existe possibilidade da migração?
O cliente usa Linux, e nós usamos Windows no nosso ambiente de testes. A
lentidão é a mesma.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
tratar todos os registros alterados usando uma trigger
FOR EACH STATEMENT. Como consequência, a única opção que me resta é a FOR
EACH ROW, que quando usada para uma atualização de 3000 registros é um
desastre.
Atenciosamente,
Mozart Hasse
___
pgbr-geral
encontramos os mesmos resultados (exceto que
um leva muito mais tempo que o outro).
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
e mais complicado do que já é.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
modelagem de *datawarehouse* ?!
Eu já expliquei em mensagens anteriores que o meu caso nem é um
datawarehouse, mas vamos lá: tem algum trecho desse livro que você possa
citar para justificar as recomendações sobre índices que está sugerindo?
Atenciosamente,
Mozart Hasse
problema. Não
é. Por enquanto o custo desse monte de índices (mesmo nas consultas, como
bem explicado pelo Charly) ainda é muito menor do que o benefício de sua
eventual utilização.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr
Euler,
Mozart Hasse escreveu:
Euler escreveu:
Você está querendo ter mais do que 32 índices em uma tabela? Há algo
errado
com o seu modelo de dados, não?
Ué, errado por quê?!
Simplesmente porque atualizar um registro implica em atualizar pelo menos 1
+
32 + 1 arquivos. Isso é
monte de FKs, e cada uma delas
quase sempre precisa de um ou dois índices. Esquartejar essa tabela em duas
ou mais considerando que eu quase sempre uso todos os 89 campos juntos soa
não só como um contra-senso como prejudica muito qualquer esperança de
desempenho.
Mozart Hasse
que *deve* ser
desse jeito. Pois bem, pode começar perguntando a ela de qual parágrafo de
que livro ela *pensa* que tirou essa idéia, pois nem no meio acadêmico ouvi
falar dessa necessidade.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
funções em C.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
padrão de uso de todas
as suas tabelas, o jeito é abortar manutenções e particionar tabela a
tabela, espalhando pelos horários de menor uso.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https
que nem um cartório, que já tem fé pública, precisa de algo tão
complexo (talvez algum cartório venha a precisar quando abrir mão do
papel...).
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https
Marcelo,
1. NÃO MANDE MENSAGENS SEM ASSUNTO para uma lista!
2. Tente isso:
select campox+1 from tabela where campox+1 not in (select campox from tabela)
limit 1
From: Marcelo Giovane nrhce...@teleon.com.br
Subject: [pgbr-geral] (sem assunto)
To: Comunidade PostgreSQL Brasileira
Leandro,
From: Leandro Müller leandr...@muriki.com.br
Subject: [pgbr-geral] sugestão para melhorar performace da consulta
Estou tentando gerar uma consulta de soma em um intervalo de 30 dias, são
vários registros para calcular, podem esta demorando em torno de 15 minutos,
creio eu que não
sinal pode ficar cheia de Cut-Paste, porém vai ser muito
simples de entender e dar manutenção, além de mais rápida. Voto na
alternativa 1.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin
sacrifiquei tudo o que poderia de
paralelismo fazendo os processos de alta prioridade não causarem deadlocks
entre si.
* Não, eu não vou esquartejar minhas transações em pedaços menores tão
cedo, se é que algum dia eu vou fazer isso só por um capricho do Postgres.
Atenciosamente,
Mozart Hasse
concretos como desempenho e simplicidade de projeto.
Para quem quer ser melhor que seus concorrentes, fica a solicitação de
inclusão dessa
funcionalidade.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https
vai comprometer o desempenho.
PS. Sei que tem material na net sobre isso, mas fiquei um pouco chateado
pelo que
já li e preciso de ajuda para eu poder tomar uma decisão.
Sugiro que vá em frente. O caminho é cheio de provações, porém ficar
parado é muito pior.
Mozart Hasse
consulta. Sim, também acho que contraria o bom
senso, mas como estamos falando do otimizador do Postgres, as chances são
boas.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br
, nunca prestei serviços para um cliente que estivesse disposto a esperar
a aplicação ficar lenta para pedir para pesquisar se índice ajuda alguma
coisa.
Se os seus são assim, trate-os a pão de ló porque são uma classe em
extinção...
Mozart Hasse
Oi Márcio,
Por ultimo quando já ia partir para reescrever a função, reduzi os
NOTICE
como vc havia falado. Cara funcionou!!
O que não entendo é isso incluenciar para o insert ficar cada vez mais
lento, eu faço em média 1.500.000 inserts cada vez que rodo a função.
Pelo visto o programa
performance tuning index
Juntar vários casos em uma wiki até que seria útil para iniciantes, resta
levantar os dados para saber como organizá-los.
Boa sorte,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https
Marcio,
Esta rotina possui vários select/update, afinal de contas ela é
responsável
por atualizar os saldos das contas contábeis.
Entao possuo uma tabela em que os lançamentos são gerados e uma outra onde
os saldos das contas sao armazenados por conta/mes/ano.
Faço igualzinho, só que no
culpa desse driver.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
perto ou tropeçar nesse limite infame com uma tabela grande). Usar números
pequenos demais é um desastre, porém caso não tenha procurado vale a pena
pesquisar valores maiores ou menores que os que você andou usando.
Quando resolver, ficarei curioso em saber o que foi.
Atenciosamente,
Mozart Hasse
conseguir
considerando nossas experiências anteriores.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
e o SQL Server fazem faz
tempo). Isso obviamente consome um tempo, porém nem se compara com o
desperdício que o Postgres faz com as estimativas furadas dele.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
mesmo
registro, sendo ou não sobre os mesmos campos, dentro da mesma transação).
Sem a estrutura das tabelas e comandos envolvidos nas suas transações, é o
que dá para sugerir.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral
sejam percorridas
(teoricamente) apenas uma vez, o que deve deixar o desempenho administrável.
Não se esqueça de que índices podem ajudar. Experimente um EXPLAIN ANALYZE
e quem sabe o otimizador te diga algo que você deixou passar.
Anteciosamente,
Mozart Hasse
Oi Dickson,
Em Thu, 25 Jun 2009 13:31:07 -0300, Mozart Hasse mozart.ha...@usa.net
escreveu:
Infelizmente o Postgres está longe de ter Common Table Expressions ou um
otimizador comparável ao do SQL Server, então o jeito é mexer na
consulta.
From: Dickson S. Guedes lis...@guedesoft.net
Apenas
otimizar chutar o índice certo.
Se isso não adiantar, o jeito vai ser esperar a implementação de um
otimizador pelo menos comparável aos do SQL Server e Oracle.
Boa sorte,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
importar todos os seus
registros.
PERGUNTA: Tem como otimizar essa consulta de alguma maneira?
Só o EXPLAIN pode te ajudar.
Dá pra usar o COPY nesse caso?
Dar, dá, só que o INSERT INTO SELECT é mais rápido no seu caso.
Atenciosamente,
Mozart Hasse
esse driver.
Sem mais sugestões,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
versão? Qual a tua string de
conexão?
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
como um todo), via triggers,
sequences, functions e views, o trabalho que alguém teria montando um sistema
para se comunicar com essa parafernália toda seria tão grande que ninguém
perderia tempo com isso.
Mozart Hasse
___
pgbr-geral mailing list
pgbr
direitinho, o usuário vai apenas ver uma
janelinha preta rodando em segundo plano enquanto tua SP cuida da zica.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman
Delphi 2007. Em cada caso topei
com vários inconvenientes específicos da interface de comunicação, porém
sempre contornáveis e não relacionados com o Postgres ou seu driver ODBC.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral
) para geração de índices e
eventuais rotinas auxiliares. Os scripts de criação de bases vazias (para
testes internos e novos clientes) também são bem grandes.
Sugestões?
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https
Bom,
Não conheço, mas escrever um programa que roda um alter table de
cada vez não parece ser muito complicado
De fato, mas não quero reinventar a roda. Colocar as firulas que eu gostaria
vai consumir muito mais tempo.
Utilize copy ao invés de inserts, ele foi feito para isso!
Ele foi
não quero ficar parando, reconfigurando e reiniciando
serviço toda a vez que quiser rodar um inocente script numa estação.
Valeu,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin
, ROLLBACK e SAVEPOINT corretamente e
estimar de quantos em quantos registros realizar um COMMIT.
Isso depende da configuração do servidor. Não quero depender disso.
Obrigado pelas dicas, mesmo que não sejam bem o que eu estava procurando.
Mozart Hasse
servir para alguém,
mas no meu caso, na-na-ni-na-não.
Mozart Hasse
Sobre o assunto, eu *não* misturaria dados de empresas distintas em uma
mesma
tabela sem utilizar um controle de permissões a nível de registros (como
os
descritos acima) porque seria fácil, senão trivial, conseguir dados
que faça isso conectando com ele.
Pois é, então finalmente a pergunta é:
Alguém conhece algum programa que faça isso ou algo parecido??
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https
, nenhuma solução trivial à vista.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Euler,
Mozart Hasse escreveu:
Com esse talvez minha
impressão é que nem você sabe o que poderia te convencer a mexer nesse
valor.
O *talvez* é porque é uma técnica empírica (sem embasamento teórico).
Eu
e muitos concordam que o valor padrão é ridículo.
Ok, em qual lista as pessoas que
qual
componente deixou as coisas instáveis, mas configurando direitinho funciona.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Mozart Hasse,
Hum... Mostre o que usou nas propriedades de conexão, talvez falte algum
parâmetro.
A forma que estou utilizando é a seguinte
AdoConnection:
Tá, e a ConnectionString??
Estou testando as configurações que vc usa, no entanto qdo uso
CursorLocation = clUseServer na
resultados, qualquer processador serve.
Se acha que esse processador é lento, seria bom mostrar que parâmetro faria
ele usar outro recurso de forma a executar a consulta num tempo decente.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral
apresentados neste tópico. A proporção previsto/encontrado
proporcionada pelo valor 1000 é o tipo de margem de erro que eu julgo
necessária num histograma de otimizador.
Sem mais para o momento,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral
tabelas grandes
precisem de mais estatísticas, geralmente proporcionais ao número de
registros, por que raios eu preciso informar valores absolutos ao invés de
percentuais? Algo contra o super prático e intuitivo SAMPLING RATE do SQL
Server?
Mozart Hasse
prove.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
default_statistics_target=1000 e veja se melhora.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
alguém. Mexer num ENUM não me parece nem de longe
tão amigável.
Sei não, não si se consigo imaginar uma boa relação custo/benefício em
favor dos tipos ENUM. Tabelas me parecem muito mais práticas.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
, sem pena, além dos que tiverem
chance de se sair melhor em consultas críticas.
Se fizer muitas consultas onde for necessário apresentar os valores das
chaves naturais, tenta criar mais um índice com a PK + AK e era isso.
Atenciosamente,
Mozart Hasse
- Original Message -
From: [EMAIL
relativamente pequena é exportada como chave estrangeira para uma
tabela filha relativamente grande.
Minha impressão é que essa sua exceção é na verdade a regra, com poucas
exceções.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral
comparado
a uma tabela.
Atenciosamente,
Mozart Hasse
2008/10/15 Euler Taveira de Oliveira [EMAIL PROTECTED]
Mozart Hasse escreveu:
* Bom, com modelos perfeitos num mundo perfeito isso até parece
razoável,
mas... voltando ao mundo real do dia-a-dia: e se eu precisar alterar a
lista
de
do ODBC DSN
(ANSI ou UNICODE). Pelo visto no meu caso ele esqueceu de fazer a conversão
ou fez duas vezes. Talvez eu arranje tempo para ir mais a fundo quando não
tiver outros problemas para resolver.
Valeu,
Mozart Hasse
___
pgbr-geral mailing list
. Coloquei UTF8 em todos os lugares (incluindo propriedades do ODBC e
strings de conexão) onde tinha LATIN1. Abro *todas* as conexões e
transações
com SET client_encoding=UTF8 e o erro persiste.
Sugestões?
Mozart Hasse
___
pgbr-geral mailing list
pgbr
posso contornar
isso?
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
de próximo passo?
Mozart Hasse
Troquei todas as referências a minha tabela dentro das functions por
public.mvtoestq ou gestao.mvtoestq. O problema é que, quando eu chego
num
comando DELETE dentro de uma function chamada pela trigger, o Postgres
reporta
o erro ERROR: record 'new
Emerson,
Mozart Hasse escreveu:
A trigger tem a intenção de atualizar os valores de alguns campos
(saldo
anterior e data inicial do próximo registro) no registro recém
incluído, de
forma a deixar o registro incluído com valores coerentes com os
registros
anteriores e posteriores, segundo
procedure para trabalhar sobre o comando ao invés de trabalhar sobre
registros da tabela seria uma mudança extremamente radical, cujas
implicações no desempenho me preocupam bastante.
Vou ler a documentação e fazer alguns testes. Obrigado pela sugestão.
Mozart Hasse
William,
From: Mozart Hasse [EMAIL PROTECTED]
Bom, quando eu usei rules em views que eram simplesmente copias da
tabela original, as mesmas eram :
CREATE RULE [nome] AS ON INSERT TO [nome view] DO INSTEAD INSERT INTO
[tabela original](COALESCE(new.[campo1],
DEFAULT),COALESCE(new
(raramente desperdiçada) de deixar a tabela com dados inconsistentes.
Grato pela atenção,
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
quaisquer aspas dos scripts de criação das
tabelas.
Atenciosamente,
Mozart Hasse
- Original Message -
From: Rafael Helm - Trevisan Tecnologia
Subject: [pgbr-geral] RES: Migração de Firebird p/ PostgreSQL
Pessoal, consegui acessar o PostgreSQL via BDE.
Mas uma vez obrigado à lista.
Agora
a isso.
Você pode tentar implementar na mão, criando funções em C chamadas a partir
de gatilhos que identificariam a aplicação cliente através de alguma
informação da conexão e mandariam o aviso por fora do banco.
Sem melhores sugestões,
Mozart Hasse
From: Fabio Alves de Araujo Ebner - Dna
Subject
precisaremos
reescrever
o código Delphi, somente adaptar algumas consultas SQL.
ALGUMAS ?! Boa sorte.
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
primeiro a falar, mas não custa ressaltar: comparar o plano das
consultas
seria muito mais elucidativo e prático do que montar baterias de testes
dessa magnitude
para tentar provar o óbvio.
Atenciosamente,
Mozart Hasse
___
pgbr-geral mailing list
pgbr
Olá,
Estou usando Delphi 2007 e anda difícil achar alguma coisa que se conecte com
o Postgres. A única coisa além do BDE que se conectou com ele foi o ADO
através do driver ODBC 8, o que não me parece o cenário ideal.
Já usando DBExpress, tanto o driver ODBC quanto o da Vita Voon são
compatíveis
planos de se deixar isso mais eficiente em alguma versão
futura?
Mozart Hasse
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
1 - 100 de 119 matches
Mail list logo
