Exists es sumamente mas rapido.
2008/11/14 Juan Ramirez <[EMAIL PROTECTED]>:
> Colegas, hoy que reviso un hilo acerca de un script recuerdo esta gran duda
> que he tenido...
>
> cual tiene más performance, yo estoy acostumbrado cuando hago relaciones
> entre tablas a utilizar "exists" en lugar de
sin embargo ahora que leo, el NOT EXISTS me parece que no es muy performante...
2008/11/14 Emanuel CALVO FRANCO <[EMAIL PROTECTED]>:
> Exists es sumamente mas rapido.
>
> 2008/11/14 Juan Ramirez <[EMAIL PROTECTED]>:
>> Colegas, hoy que reviso un hilo acerca de un script recuerdo esta gran duda
>>
> sin embargo ahora que leo, el NOT EXISTS me parece que no es muy
> performante...
>
> 2008/11/14 Emanuel CALVO FRANCO <[EMAIL PROTECTED]>:
> > Exists es sumamente mas rapido.
> >
> > 2008/11/14 Juan Ramirez <[EMAIL PROTECTED]>:
> >> Colegas, hoy que reviso un hilo acerca de un script recuerdo
Juan Ramirez escribió:
> cual tiene más performance, yo estoy acostumbrado cuando hago
> relaciones entre tablas a utilizar "exists" en lugar de los join.
Depende de cada caso particular. Y hay que tener muy en cuenta que a
veces IN es muy rapido, en cambio NOT IN es muy lento; y ahi donde
EXIST
> Depende de cada caso particular. Y hay que tener muy en cuenta que a
> veces IN es muy rapido, en cambio NOT IN es muy lento; y ahi donde
> EXISTS pueda ser muy rapido, NOT EXISTS puede ser muy lento y
> viceversa. Y en todos los casos hay que tener mucho cuidado con la
> forma en que se resue
[GENERAL] 8.3.1 query plan
[GENERAL] Slow query performance
estos dos thread tratan el tema en profundidad.
El día 14 de noviembre de 2008 19:10, Alvaro Herrera
<[EMAIL PROTECTED]> escribió:
> Juan Ramirez escribió:
>
>> cual tiene más performance, yo estoy acostumbrado cuando hago
>> relaciones
- Original Message -
From: "Alvaro Herrera" <[EMAIL PROTECTED]>
To: "Juan Ramirez" <[EMAIL PROTECTED]>
Cc: "PostGreSQL Lista de Ayuda"
Sent: Friday, November 14, 2008 4:10 PM
Subject: Re: [pgsql-es-ayuda] join - versus - exists [performance]
Raul Andres Duque escribió:
> El optimizador aprende?
No. Los desarrolladores (Tom Lane) agregan más código.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"Por suerte hoy explotó el califont porque si no me habría muerto
de aburrido" (Papelucho)
--
TIP 9: v
On Fri, Nov 14, 2008 at 5:32 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Raul Andres Duque escribió:
>
>> El optimizador aprende?
>
> No. Los desarrolladores (Tom Lane) agregan más código.
>
De hecho hace poco aprendi a manejar semi-joins y anti-joins para
manejar esos casos precisamente (cre
On Sat, Nov 15, 2008 at 12:50 AM, Jaime Casanova
<[EMAIL PROTECTED]> wrote:
> On Fri, Nov 14, 2008 at 5:32 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>> Raul Andres Duque escribió:
>>
>>> El optimizador aprende?
>>
>> No. Los desarrolladores (Tom Lane) agregan más código.
>>
>
> De hecho hace p
2008/11/15 Jaime Casanova <[EMAIL PROTECTED]>:
> On Sat, Nov 15, 2008 at 12:50 AM, Jaime Casanova
> <[EMAIL PROTECTED]> wrote:
>> On Fri, Nov 14, 2008 at 5:32 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>>> Raul Andres Duque escribió:
>>>
El optimizador aprende?
>>>
>>> No. Los desarrollado
> 2008/11/15 Jaime Casanova <[EMAIL PROTECTED]>:
> Y mas menos dentro de este mismo contexto bajo su punto de vista que
> es mejor usar, cruzamiento de tablas de la manera
>
> Select a.campo1
> b.campo2
> From Foo1 a,
> Foo2 b
> Where a.id = b.id
>
> O usar producto cartesiano
del sql anci...
Si alguien me indica alguna manera de evitar el left join y right join, asi
como en oracle existe el operador (+) el mismo que se coloca en cualquiera de
los lados de las comparaciones donde se conoce que no va a tener la información.
Saludos Cordiales
Alfonso :)
From: [EMAIL PRO
2008/11/16 ALFONSO REYES <[EMAIL PROTECTED]>:
>
> Si alguien me indica alguna manera de evitar el left join y right join, asi
> como en oracle existe el operador (+) el mismo que se coloca en cualquiera
> de los lados de las comparaciones donde se conoce que no va a tener la
> información.
>
no ex
ALFONSO REYES escribió:
>
> Estimados yo soy nuevo con la base postgres, pero en oracle e manejado
> grandes volumenes, y les comento que la clausula "EXISTS"como "NO
> EXISTS" para subconsultas es mucho pero mucho mas rapido que el "IN" o
> "NOT IN", siempre y cuando la subconsulta sea un sql y n
2008/11/17 Alvaro Herrera <[EMAIL PROTECTED]>:
> ALFONSO REYES escribió:
>>
>> Estimados yo soy nuevo con la base postgres, pero en oracle e manejado
>> grandes volumenes, y les comento que la clausula "EXISTS"como "NO
>> EXISTS" para subconsultas es mucho pero mucho mas rapido que el "IN" o
>> "NO
Relacionado con el tema:
http://es.wikipedia.org/wiki/Join
Específicamente "notación implícita"
El 17 de noviembre de 2008 6:08, Javier Chávez B. <[EMAIL PROTECTED]>escribió:
> 2008/11/17 Alvaro Herrera <[EMAIL PROTECTED]>:
> > ALFONSO REYES escribió:
> >>
> >> Estimados yo soy nuevo con la ba
17 matches
Mail list logo
