A sim, neste caso seria a regra matemática por assim dizer, ufa, pensei que
fosse a respeito da nomenclatura.

É o velho esquema (1 + 2 * 3) é diferente de ((1 + 2) * 3)

Já ia pensando que teria que rever todas as minhas Querys rsrsrs


Em 17 de julho de 2013 15:27, Alessandro Gonçalves <[email protected]>escreveu:

> Se o c3 tiver uma seletividade maior que c1 o banco vai respeitar os
> parenteses e vai primeiramente  considerar o c1
>
> SELECT * FROM TABELA WHERE ((c1 == 1) AND c3 == 1)
>
>
> Em 17 de julho de 2013 15:16, Marcelo da Silva <[email protected]>escreveu:
>
> Opa... Euler, um detalhe me chamou a atenção:
>>
>> " (é claro que ele vai respeitar a ordem indicada
>> com parênteses)."
>>
>> Como assim, poderia dar um exemplo num simples SQL ?
>>
>> Gostaria de saber sobre isso, pois eu sempre separo as condições entre
>> parenteses
>>
>> SELECT * FROM TABELA WHERE (CONDICAO1)AND(CONDICAO2) ETC
>>
>> Faço isso para melhor leitura mesmo... vai que estou errando...
>>
>>
>>
>> Em 17 de julho de 2013 15:09, Euler Taveira <[email protected]>escreveu:
>>
>> On 17-07-2013 12:58, [email protected] wrote:
>>> > Vou "aproveitar" uma explicação que tive de um DBA Oracle...(eu sei, a
>>> > lista é de PG)...
>>> >
>>> Oracle *não* é Postgres. ;)
>>>
>>> > " Procure no where sempre colocar os campos que pertencem a chave de
>>> > indice da tabela, na mesma ordem se a chave for composta, pois o banco
>>> > utiliza a estatistica para realizar a pesquisa e se a chave for
>>> composta
>>> > e a formatacao da filtragem nao for igual a chave, entao o fitro será
>>> > feito sem utilizar a estatistica da tabela  "
>>> >
>>> Isso não é verdade! O otimizador é esperto o suficiente para utilizar
>>> primeiro os campos com *maior* seletividade independente da ordem em que
>>> eles aparecem no WHERE (é claro que ele vai respeitar a ordem indicada
>>> com parênteses).
>>>
>>> Se o outro banco de dados faz isso, ele está anos-luz atrás do Postgres
>>> -- que já faz isso a bastante tempo. Porém, duvido que isso seja verdade
>>> no banco de dados do Larry.
>>>
>>>
>>> --
>>>    Euler Taveira                   Timbira - http://www.timbira.com.br/
>>>    PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>>> _______________________________________________
>>> pgbr-geral mailing list
>>> [email protected]
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>
>>
>>
>> --
>> Marcelo Silva
>> ----------------------------------------------------------------
>> Desenvolvedor Delphi / PHP
>> My Postgres database
>> Cel.: (11) 99693-4251
>>
>> _______________________________________________
>> pgbr-geral mailing list
>> [email protected]
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
>
> --
> *   *Alessandro Gonçalves
> Programador de Sistemas para Web
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>


-- 
Marcelo Silva
----------------------------------------------------------------
Desenvolvedor Delphi / PHP
My Postgres database
Cel.: (11) 99693-4251
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a