| From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(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 03:38:10 |
| Message-ID: | CAFjFpRcJBtGgxzHD2=RpOpuGc06xtqtaRtkVbmt7iUPovXdowA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2016-09-14 03:58:07 | Re: kqueue |
| Previous Message | Pavan Deolasee | 2016-09-14 03:17:25 | Re: Vacuum: allow usage of more than 1GB of work mem |