From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | 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-20 16:29:32 |
Message-ID: | CA+TgmoZt=JpVvCepS5pxu2M-SOwh_50AXDyUvEDDxqyG58FX1A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 20, 2017 at 9:44 AM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> Right. If we could use parent Vars to indicate parent Var or child Var
> depending upon the context, a lot of memory issues would be solved; we
> wouldn't need to translate a single expression. But I think that's not
> straight forward. I have been thinking about some kind of polymorphic
> Var node, but it seems a lot more invasive change. Although, if we
> could get something like that, we would save a huge memory. :)
Yes, that's why I'm interested in exploring that approach once the
basic framework is in place here.
> I am wondering whether we need to change
> calc_non_nestloop_required_outer() similar to
> calc_nestloop_required_outer() just to keep their signatures in sync.
I haven't looked at the patch, but I don't think you need to worry about that.
> Should I work on completing reparamterized_path_by_child() to support
> all kinds of paths?
Yes, or at the very least all scans, like reparameterize_path() already does.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Banck | 2017-03-20 16:32:12 | Re: Create replication slot in pg_basebackup if requested and not yet present |
Previous Message | Robert Haas | 2017-03-20 16:28:06 | Re: Partition-wise join for join between (declaratively) partitioned tables |