Re: [HACKERS] GEQO optimizer (was Re: Backend message type 0x44 arrived while idle) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] GEQO optimizer (was Re: Backend message type 0x44 arrived while idle)
Date
Msg-id 9144.926948658@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] GEQO optimizer (was Re: Backend message type 0x44 arrived while idle)  (Oleg Bartunov <oleg@sai.msu.su>)
Responses Re: [HACKERS] GEQO optimizer (was Re: Backend message type 0x44 arrived while idle)  (Oleg Bartunov <oleg@sai.msu.su>)
Re: [HACKERS] GEQO optimizer (was Re: Backend message type 0x44 arrived while idle)  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
Oleg Bartunov <oleg@sai.msu.su> writes:
> I confirm big join with 11 tables doesn't eats all memory+swap on
> my Linux box as before and  it runs *forever* :-).  It took already
> 18 minutes of CPU (P200, 64Mb) ! Will wait. 

18 minutes???  It takes barely over a minute on my aging 75MHz HP-PA
box.  (Practically all of which is planning time, since there are only
10 tuples to join... or are you doing this on a realistically sized
set of tables now?)

> This query doesn't use (expicitly) GEQO

> select t0.a,t1.a as t1,t2.a as t2,t3.a as t3,t4.a as t4,t5.a as t5,t6.a as t6,t7.a as t7,t8.a as t8,t9.a as t9,t10.a
ast10
 
>  from t0  ,t1,t2,t3,t4,t5,t6,t7,t8,t9,t10
>  where t1.a_id = t0.a_t1_id and t2.a_id=t0.a_t2_id and t3.a_id=t0.a_t3_id and t4.a_id=t0.a_t4_id and
t5.a_id=t0.a_t5_idand t6.a_id=t0.a_t6_id and t7.a_id=t0.a_t7_id and t8.a_id=t0.a_t8_id and t9.a_id=t0.a_t9_id and
t10.a_id=t0.a_t10_id;
 

No, but since there are 11 tables mentioned, it will be sent to the GEQO
optimizer anyway with the default GEQO threshold of 11...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Erik Riedel
Date:
Subject: Re: [HACKERS] 64-bit hashjoins
Next
From: Oleg Bartunov
Date:
Subject: Re: [HACKERS] GEQO optimizer (was Re: Backend message type 0x44 arrived while idle)