From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Push down more full joins in postgres_fdw |
Date: | 2016-09-14 15:22:38 |
Message-ID: | CA+TgmoYSockpYnS1TZTkPkJipveERuu6AZCR12NWFw5iB2RJxw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Sep 13, 2016 at 11:38 PM, Ashutosh Bapat
<ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> On Tue, Sep 13, 2016 at 10:28 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Sep 6, 2016 at 9:07 AM, Ashutosh Bapat
>> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
>>> That's not true with the alias information. As long as we detect which
>>> relations need subqueries, their RTIs are enough to create unique aliases
>>> e.g. if a relation involves RTIs 1, 2, 3 corresponding subquery can have
>>> alias r123 without conflicting with any other alias.
>>
>> What if RTI 123 is also used in the query?
>
> Good catch. I actually meant some combination of 1, 2 and 3, which is
> unique for a join between r1, r2 and r3. How about r1_2_3 or
> r1_r2_r3?
Sure, something like that can work, but if you have a big enough join
the identifier might get too long. I'm not sure why it wouldn't work
to just use the lowest RTI involved in the join, though; the others
won't appear anywhere else at that query level.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Claudio Freire | 2016-09-14 15:24:13 | Re: Vacuum: allow usage of more than 1GB of work mem |
Previous Message | Robert Haas | 2016-09-14 15:17:48 | Re: Vacuum: allow usage of more than 1GB of work mem |