Re: BUG #6335: Weird planner decision with exists (a join b) condition
От | Maxim Boguk |
---|---|
Тема | Re: BUG #6335: Weird planner decision with exists (a join b) condition |
Дата | |
Msg-id | CAK-MWwTNx1DCxuJsXakY-0czYdnn2Rq=ArJZqCcK7n5DVSgD7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6335: Weird planner decision with exists (a join b) condition (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: BUG #6335: Weird planner decision with exists (a join b) condition
|
Список | pgsql-bugs |
Here goes self-contained test case. I tested it on the 9.1.2, 9.1.1, 9.0.5, 9.0.4, 8.4.7 all of them affected by the problem: select version(); drop table if exists test1; drop table if exists test2; drop table if exists test3; CREATE TABLE test1 AS SELECT user_id FROM generate_series(1,1000000) AS gs(user_id); CREATE TABLE test2 AS SELECT user_id,user_id AS resume_id FROM generate_series(1,1000000) AS gs(user_id); CREATE TABLE test3 AS SELECT user_id AS resume_id FROM generate_series(1,1000000) AS gs(user_id); create index test1_user_id_key on test1(user_id); create index test2_user_id_key on test2(user_id); create index test2_resume_id_key on test2(resume_id); create index test3_resume_id_key on test3(resume_id); analyze test1; analyze test2; analyze test3; --good EXPLAIN ANALYZE select * from test1 where test1.user_id in (100) and exists ( SELECT * from test2 join test3 using (resume_id) where test2.user_id =3D test1.user_id ); --bad EXPLAIN ANALYZE select * from test1 where test1.user_id in (100, 101) and exists ( SELECT * from test2 join test3 using (resume_id) where test2.user_id =3D test1.user_id ); On Thu, Dec 15, 2011 at 1:00 AM, Alvaro Herrera <alvherre@commandprompt.com>wrote: > > Excerpts from maxim.boguk's message of mi=C3=A9 dic 14 08:09:38 -0300 201= 1: > > > But once I add second value into IN list plan become completely screwed: > > See here: > > http://archives.postgresql.org/message-id/1309918036-sup-4092@alvh.no-ip.= org > Perhaps it's a similar problem. > > Maybe you'd get enthused enough to try to fix the problem? > > -- > =C3=81lvaro Herrera <alvherre@commandprompt.com> > The PostgreSQL Company - Command Prompt, Inc. > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > --=20 Maxim Boguk Senior Postgresql DBA. Phone RU: +7 910 405 4718 Phone AU: +61 45 218 5678 Skype: maxim.boguk Jabber: maxim.boguk@gmail.com LinkedIn profile: http://nz.linkedin.com/in/maximboguk If they can send one man to the moon... why can't they send them all? =D0=9C=D0=BE=D0=B9=D0=9A=D1=80=D1=83=D0=B3: http://mboguk.moikrug.ru/ =D0=A1=D0=B8=D0=BB=D0=B0 =D1=81=D0=BE=D0=BB=D0=BE=D0=BC=D1=83 =D0=BB=D0=BE= =D0=BC=D0=B8=D1=82, =D0=BD=D0=BE =D0=BD=D0=B5 =D0=B2=D1=81=D0=B5 =D0=B2 =D0= =BD=D0=B0=D1=88=D0=B5=D0=B9 =D0=B6=D0=B8=D0=B7=D0=BD=D0=B8 - =D1=81=D0=BE= =D0=BB=D0=BE=D0=BC=D0=B0, =D0=B4=D0=B0 =D0=B8 =D1=81=D0=B8=D0=BB=D0=B0 =D0= =B4=D0=B0=D0=BB=D0=B5=D0=BA=D0=BE =D0=BD=D0=B5 =D0=B2=D1=81=D0=B5.
В списке pgsql-bugs по дате отправления: