On Mon, Jan 25, 2016 at 9:09 PM, Kouhei Kaigai <kai...@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+3r...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
