|From:||Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Partition-wise join for join between (declaratively) partitioned tables|
|Views:||Raw Message | Whole Thread | Download mbox|
>> I don't think we will get away by supporting just scan paths, since
>> the inner side of lateral join can be any paths not just scan path. Or
>> you are suggesting that we disable partition-wise lateral join and
>> support reparameterization of only scan paths?
> I think if you can do a straight-up partitionwise nested loop between
> two tables A and B, that's pretty bad.
> But if there are more complex
> cases that involve parameterizing entire join trees which aren't
> covered, that's less bad. Parallel query almost entirely punts on
> LATERAL right now, and nobody's complained yet. I'm sure that'll need
> to get fixed someday, but not today.
I am suggesting this possibility in case we run of time to review and
commit reparameterize_path_by_child() entirely. If we can do that, I
will be happy.
In case, we have to include a stripped down version of
reparameterize_path_by_child(), with which I am fine too, we will need
to disable LATERAL joins, so that we don't end up with an error "could
not devise a query plan for the given query".
The Postgres Database Company
|Next Message||Craig Ringer||2017-03-23 04:30:42||Re: Logical decoding on standby|
|Previous Message||Craig Ringer||2017-03-23 04:22:23||Re: [PATCH] Transaction traceability - txid_status(bigint)|