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-
> 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
As I said upthread, in general your proposal will not work and will
lead to wrong answers to queries.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: