Re: Bad performance of SELECT ... where id IN (...)
От
Omar Kilani
Тема
Re: Bad performance of SELECT ... where id IN (...)
Дата
Msg-id
f0cc3e3e0910050524n13903ef3t66c1e3416306fd72@mail.gmail.com
Ответ на
Re: Bad performance of SELECT ... where id IN (...) (Robert Haas)
Список
Дерево обсуждения
Bad performance of SELECT ... where id IN (...) Xia Qingran <qingran.xia@gmail.com>
Re: Bad performance of SELECT ... where id IN (...) Tom Lane <tgl@sss.pgh.pa.us>
Re: Bad performance of SELECT ... where id IN (...) Xia Qingran <qingran.xia@gmail.com>
Re: Bad performance of SELECT ... where id IN (...) Ivan Voras <ivoras@freebsd.org>
Re: Bad performance of SELECT ... where id IN (...) Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: Bad performance of SELECT ... where id IN (...) Craig James <craig_james@emolecules.com>
Re: Bad performance of SELECT ... where id IN (...) Xia Qingran <qingran.xia@gmail.com>
Re: Bad performance of SELECT ... where id IN (...) Omar Kilani <omar.kilani@gmail.com>
Re: Bad performance of SELECT ... where id IN (...) Robert Haas <robertmhaas@gmail.com>
Re: Bad performance of SELECT ... where id IN (...) Omar Kilani <omar.kilani@gmail.com>
Re: Bad performance of SELECT ... where id IN (...) Grzegorz Jaśkiewicz <gryzman@gmail.com>
Re: Bad performance of SELECT ... where id IN (...) Xia Qingran <qingran.xia@gmail.com>
Re: Bad performance of SELECT ... where id IN (...) Kenneth Marshall <ktm@rice.edu>
Re: Bad performance of SELECT ... where id IN (...) Claus Guttesen <kometen@gmail.com>
Re: Bad performance of SELECT ... where id IN (...) Paul Ooi <paul@takizo.com>
Robert, On Mon, Oct 5, 2009 at 11:01 PM, Robert Haas wrote: > On Sun, Oct 4, 2009 at 9:58 PM, Omar Kilani wrote: >> Hi Xia, >> >> Try this patch: >> >> http://treehou.se/~omar/postgresql-8.4.1-array_sel_hack.patch >> >> It's a hack, but it works for us. I think you're probably spending >> most of your query time planning, and this patch helps speed things up >> 10x over here. > > Woof. I can see that helping in some situations, but what a foot-gun! We've run that patch for about 4 years (originally coded for us by Neil Conway for 8.2, I think), and have never seen any negatives from it. I'm not really sure what the alternatives are -- it never really makes sense to get the selectivity for thousands of items in the IN clause. I've never seen a different plan for the same query against a DB with that patch vs without -- it just takes a huge amount of time longer to run without it. :) But yeah, definitely a hack, and should only be used if needed -- hopefully there's some sort of official solution on the horizon. :) > ...Robert Regards, Omar
В списке pgsql-performance по дате отправления
