[pgbr-geral] Lentidão apresentação consulta
Bom dia, Ontem percebi que ao realizar uma consulta no banco de dados, o tempo para consulta esta rápida, porem o tempo para apresentar o retorno está lento demais, levando até 8s, sendo que a consulta foi realizada em 286ms. Alguém já viu isto antes? o banco de dados está em uma rede externa e eu acesso ele remotamente via pgAdmin versão do pgAdmin 1.18.1 versão do banco 9.3.1 Isso começou sem eu atualizar nada. Att. Jean ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] lo_import em banco de dados remoto
Mandei uma pergunta similar a essa, mas como tinha poucas informações
talvez isso implicou em se obter uma resposta. Dessa forma estou
reformulando a pergunta com mais informação bem como com novas descobertas.
Pela primeira vez estou precisando gravar arquivos no banco. No meu caso
eu optei por usar coluna do tipo OID.
Em uma base de dados localhost, o insert seria assim:
|INSERT INTO fruit VALUES ('peach', lo_import('/usr/images/peach.jpg'));|
Mas e se eu precisar inserir esse mesmo arquivo em um banco de dados remoto?
Nesse exemplo de insert que fiz funciona se a base de dados estiver
local, pois |lo_import| irá buscar o arquivo na máquina onde está
instalado o servidor.
Mas eu preciso fazer um insert de uma máquina cliente, ou seja, o
arquivo está na máquina cliente e o insert deve mandar esse arquivo da
máquina cliente para o servidor.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] poor performance usando ILIKE - PostgreSQL 9.2
2016-05-16 23:19 GMT+12:00 Rafael Fialho :
> Você pode desacentuar e minimizar o contéudo passado como parâmetro e
>>> manter o LIKE.
>>>
>>> `WHERE lower(functionDesacentua(col)) LIKE
>>> lower(functionDesacentua(texto)) || '%'`
>>>
>>>
>>
>> O meu problema aqui é que o LIKE é case-sensitive... ou seja.. estou
>> pesquisando por RYAN SHOWER mas não sei se essas palavras estão em
>> maiúscula ou minúscula... portanto.. o LIKE me retorna 0 rows.
>>
>
> Bom dia!
> Pois é justamente pra isso que os dois "lower()" são utilizados, assim
> estarás convertendo o texto para lower case e o campo a ser pesquisado
> também, eliminando o trabalho do ilike, podendo utilizar like, pois a
> pesquisa funcionará mesmo sendo case sensitive.
> Pra isso, o índice também precisa ser criado com lower(col), ou qualquer
> outra transformação non-volatile que o campo sofra.
>
>
Certo. Obrigado, Rafael.
*Nova query: (O clientid está diferente apenas por motivos de WARM data)*
> SELECT DISTINCT title
> FROM public.ja_jobs WHERE lower(title) LIKE lower('RYAN
> SHOWER')
> AND clientid = 31239
> AND time_job > 1457826264
> order BY title
> limit 10;
*Index:*
> CREATE INDEX CONCURRENTLY ON public.ja_jobs (clientid, lower(title)
> varchar_pattern_ops, time_job);
Desse modo está funcionando perfeitamente bem. E a query, de quase 3
segundos passou à ser executada em 300ms.
Entretanto, tive que deixar o DISTINCT. Mas isto não afetou a performance.
Obrigado.
Lucas
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Funcão PostgreSQL 9.2
Apenas um UPDATE. Com o código à cima, IF (TG_OP = 'INSERT') THEN > UPDATE public.companies SET client_code_increment = > (client_code_increment + 1) WHERE id = NEW.company_id; Mesmo que o usuário não incluísse data, ele atualizava para o próximo valor. Isto estava errado. Segue a correção: IF (TG_OP = 'INSERT') AND NEW.code IS NULL THEN > UPDATE public.companies SET client_code_increment = > (client_code_increment + 1) WHERE id = NEW.company_id; Obrigado. Lucas ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
