Re: Partition-wise join for join between (declaratively) partitioned tables

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
Date: 2017-03-23 04:22:52
Message-ID: CAFjFpRdEXxtRd0y_7E6wM9x2mJkxuMQQXz4dFmUUomjn9tCyMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

>
>> 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.

Ok.

> 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.
>
Ok.

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".

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

In response to

Browse pgsql-hackers by date

  From Date Subject
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)