Re: [Proposal] Table partition + join pushdown
От | Robert Haas |
---|---|
Тема | Re: [Proposal] Table partition + join pushdown |
Дата | |
Msg-id | CA+TgmoZoWwctho--Pt93ap-b002V2JKcEK5Sq_eoG6cOKyWDeg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Proposal] Table partition + join pushdown (Kouhei Kaigai <kaigai@ak.jp.nec.com>) |
Список | pgsql-hackers |
On Mon, Jan 25, 2016 at 9:09 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: > Of course, its implementation is not graceful enough, especially, above > point because this extra filter will change expected number of rows to > be produced by inner relation, and relevant cost. > Right now, his patch calls cost_seqscan() and others according to the > type of inner relation by itself. Of course, it is not a portable way, > if inner relation would not be a simple relations scan. > > Due to path construction staging, AppendPath with underlying join paths > has to be constructed on join path investigation steps. So, what is the > reasonable way to make inner relation's path node with filters pushed- > down? > It is the most ugly part of the current patch. I think that it needs to be done only in contexts where we can guarantee that the optimization is correct, like declarative hash partitioning: http://www.postgresql.org/message-id/CA+Tgmob2wfJivFoCDLuUnovJsFTp6QsqxiPpxvNNoGLY+3rjbg@mail.gmail.com As I said upthread, in general your proposal will not work and will lead to wrong answers to queries. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: