On 2017/03/17 2:35, Robert Haas wrote:
And ... I don't see anything to complain about, so, committed.
Thanks for committing, Robert! Thanks for reviewing, Ashutosh and David!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Thu, Mar 16, 2017 at 12:48 PM, Robert Haas wrote:
> On Thu, Mar 16, 2017 at 11:46 AM, David Steele wrote:
>> $ patch -p1 < ../other/postgres-fdw-subquery-support-v15.patch
>> patching file contrib/postgres_fdw/deparse.c
>> Hunk #11 succeeded at 1371 (offset -3 lines).
>> Hunk #12 succeeded at
On Thu, Mar 16, 2017 at 11:46 AM, David Steele wrote:
> $ patch -p1 < ../other/postgres-fdw-subquery-support-v15.patch
> patching file contrib/postgres_fdw/deparse.c
> Hunk #11 succeeded at 1371 (offset -3 lines).
> Hunk #12 succeeded at 1419 (offset -3 lines).
> Hunk #13 succeeded at 1486 (offset
On 1/30/17 6:30 AM, Etsuro Fujita wrote:
> On 2017/01/27 21:25, Etsuro Fujita wrote:
>> On 2017/01/27 20:04, Ashutosh Bapat wrote:
>>> I think we should pick up your patch on
>>> 27th December, update the comment per your mail on 5th Jan. I will
>>> review it once and list down the things left to c
On Mon, Jan 30, 2017 at 8:30 PM, Etsuro Fujita
wrote:
> Other changes:
> * I went back to make_outerrel_subquery and make_innerrel_subquery, which
> are flags to indicate whether to deparse the input relations as subqueries.
> is_subquery_rel would work well for handling the cases of full joins wi
On 2017/01/30 21:05, Ashutosh Bapat wrote:
On Mon, Jan 30, 2017 at 5:00 PM, Etsuro Fujita
wrote:
On 2017/01/27 21:25, Etsuro Fujita wrote:
Sorry, I started thinking we went in the wrong direction. I added to
deparseSelectStmtForRel build_subquery_tlists, which creates a tlist for
each subquer
On Mon, Jan 30, 2017 at 5:00 PM, Etsuro Fujita
wrote:
> On 2017/01/27 21:25, Etsuro Fujita wrote:
>>
>> On 2017/01/27 20:04, Ashutosh Bapat wrote:
>>>
>>> I think we should pick up your patch on
>>> 27th December, update the comment per your mail on 5th Jan. I will
>>> review it once and list down
On 2017/01/27 21:25, Etsuro Fujita wrote:
On 2017/01/27 20:04, Ashutosh Bapat wrote:
I think we should pick up your patch on
27th December, update the comment per your mail on 5th Jan. I will
review it once and list down the things left to committer's judgement.
Sorry, I started thinking we w
On 2017/01/27 20:04, Ashutosh Bapat wrote:
On Fri, Jan 13, 2017 at 12:30 PM, Etsuro Fujita
wrote:
A more clean way I'm thinking is: (1) in
postgresGetForeignJoinPaths(), create a tlist by build_tlist_to_deparse()
and save it in fpinfo->tlist before estimate_path_cost_size() if
use_remote_estima
On Fri, Jan 13, 2017 at 12:30 PM, Etsuro Fujita
wrote:
> On 2017/01/12 18:25, Ashutosh Bapat wrote:
>>
>> On Wed, Jan 11, 2017 at 5:45 PM, Etsuro Fujita
>> wrote:
>
>
> On 2017/01/05 21:11, Ashutosh Bapat wrote:
>>
>> IIUC, for a relation with use_remote_estimates we will deparse the
On 2017/01/12 18:25, Ashutosh Bapat wrote:
On Wed, Jan 11, 2017 at 5:45 PM, Etsuro Fujita
wrote:
On 2017/01/05 21:11, Ashutosh Bapat wrote:
IIUC, for a relation with use_remote_estimates we will deparse the
query twice and will build the targetlist twice.
While working on this, I noticed
On Wed, Jan 11, 2017 at 5:45 PM, Etsuro Fujita
wrote:
> On 2017/01/05 21:38, Ashutosh Bapat wrote:
>>
>> On Thu, Jan 5, 2017 at 5:51 PM, Etsuro Fujita
>> wrote:
>>>
>>> On 2017/01/05 21:11, Ashutosh Bapat wrote:
>
>
> On 2017/01/03 17:28, Ashutosh Bapat wrote:
>>
>> Also, in this func
On 2017/01/05 21:38, Ashutosh Bapat wrote:
On Thu, Jan 5, 2017 at 5:51 PM, Etsuro Fujita
wrote:
On 2017/01/05 21:11, Ashutosh Bapat wrote:
On 2017/01/03 17:28, Ashutosh Bapat wrote:
Also, in this function, if fpinfo->tlist is already set, why do we want
to
build it again?
IIUC, for a rel
On Thu, Jan 5, 2017 at 5:51 PM, Etsuro Fujita
wrote:
> On 2017/01/05 21:11, Ashutosh Bapat wrote:
>>
>> On Thu, Jan 5, 2017 at 5:14 PM, Etsuro Fujita
>> wrote:
>>>
>>> On 2017/01/03 17:28, Ashutosh Bapat wrote:
In build_subquery_tlists(), why don't we handle base relations?
+ if
On 2017/01/05 21:11, Ashutosh Bapat wrote:
On Thu, Jan 5, 2017 at 5:14 PM, Etsuro Fujita
wrote:
On 2017/01/03 17:28, Ashutosh Bapat wrote:
In build_subquery_tlists(), why don't we handle base relations?
+ if (foreignrel->reloptkind != RELOPT_JOINREL)
+ return;
The reason for that is
On Thu, Jan 5, 2017 at 5:14 PM, Etsuro Fujita
wrote:
> On 2017/01/03 17:28, Ashutosh Bapat wrote:
>
> I wrote:
>>>
>>> I updated the patch a bit further: simplified the function name
>>> (s/build_subquery_rel_tlists/build_subquery_tlists/), and revised
>>> comments a
>>> little bit. Attached is a
On 2017/01/03 17:28, Ashutosh Bapat wrote:
I wrote:
I updated the patch a bit further: simplified the function name
(s/build_subquery_rel_tlists/build_subquery_tlists/), and revised comments a
little bit. Attached is an updated version
(postgres-fdw-subquery-support-v14.patch).
Few comments
>
> I updated the patch a bit further: simplified the function name
> (s/build_subquery_rel_tlists/build_subquery_tlists/), and revised comments a
> little bit. Attached is an updated version
> (postgres-fdw-subquery-support-v14.patch). And I rebased another patch for
> PHVs against that patch, w
On 2016/12/08 21:08, Etsuro Fujita wrote:
On 2016/12/07 20:23, Etsuro Fujita wrote:
My proposal here would be a bit different from what you proposed; right
before deparseSelectSql in deparseSelectStmtForRel, build the tlists for
relations present in the given jointree that will be deparsed as
su
On 2016/12/07 20:23, Etsuro Fujita wrote:
On 2016/12/07 15:39, Ashutosh Bapat wrote:
On 2016/11/22 18:28, Ashutosh Bapat wrote:
I guess, the reason why you are doing it this way, is SELECT clause for
the
outermost query gets deparsed before FROM clause. For later we call
deparseRangeTblRef()
On 2016/12/07 21:11, Ashutosh Bapat wrote:
On Wed, Dec 7, 2016 at 4:51 PM, Etsuro Fujita
wrote:
On 2016/12/05 20:20, Ashutosh Bapat wrote:
3. Why is foreignrel variable changed to rel?
-extern void deparseSelectStmtForRel(StringInfo buf, PlannerInfo *root,
-RelOptInfo
On Wed, Dec 7, 2016 at 4:51 PM, Etsuro Fujita
wrote:
> On 2016/12/05 20:20, Ashutosh Bapat wrote:
>>
>> On Mon, Nov 28, 2016 at 3:52 PM, Etsuro Fujita
>> wrote:
>>>
>>> On 2016/11/24 21:45, Etsuro Fujita wrote:
* I removed make_outerrel_subquery/make_innerrel_subquery from fpinfo
a
On 2016/12/07 15:39, Ashutosh Bapat wrote:
On 2016/11/22 18:28, Ashutosh Bapat wrote:
I guess, the reason why you are doing it this way, is SELECT clause for
the
outermost query gets deparsed before FROM clause. For later we call
deparseRangeTblRef(), which builds the tlist. So, while deparsin
On 2016/12/05 20:20, Ashutosh Bapat wrote:
On Mon, Nov 28, 2016 at 3:52 PM, Etsuro Fujita
wrote:
On 2016/11/24 21:45, Etsuro Fujita wrote:
* I removed make_outerrel_subquery/make_innerrel_subquery from fpinfo
and added a new member "is_subquery_rel" to fpinfo, as a flag on whether
to deparse t
>
>
> Ashutosh proposed this to do the comparison:
>
> On 2016/11/22 18:28, Ashutosh Bapat wrote:
>>
>> I guess, the reason why you are doing it this way, is SELECT clause for
>> the
>> outermost query gets deparsed before FROM clause. For later we call
>> deparseRangeTblRef(), which builds the tli
On Wed, Dec 7, 2016 at 1:57 AM, Robert Haas wrote:
> On Mon, Dec 5, 2016 at 6:20 AM, Ashutosh Bapat
> wrote:
>> 4. I am still not happy with this change
>> +/*
>> + * Since (1) the expressions in foreignrel's reltarget doesn't
>> contain
>> + * any PHVs and (2) foreignrel
On 2016/12/07 5:27, Robert Haas wrote:
On Mon, Dec 5, 2016 at 6:20 AM, Ashutosh Bapat
wrote:
4. I am still not happy with this change
+/*
+ * Since (1) the expressions in foreignrel's reltarget doesn't contain
+ * any PHVs and (2) foreignrel's local_conds is empty, the t
On Mon, Dec 5, 2016 at 6:20 AM, Ashutosh Bapat
wrote:
> 4. I am still not happy with this change
> +/*
> + * Since (1) the expressions in foreignrel's reltarget doesn't
> contain
> + * any PHVs and (2) foreignrel's local_conds is empty, the tlist
> + * created by b
On Mon, Nov 28, 2016 at 3:52 PM, Etsuro Fujita
wrote:
> On 2016/11/24 21:45, Etsuro Fujita wrote:
>>
>> On 2016/11/22 18:28, Ashutosh Bapat wrote:
>>>
>>> The comments should explain why is the assertion true.
>>> +/* Shouldn't be NIL */
>>> +Assert(tlist != NIL);
>
>
>> I noticed
On 2016/11/24 21:45, Etsuro Fujita wrote:
On 2016/11/22 18:28, Ashutosh Bapat wrote:
The comments should explain why is the assertion true.
+/* Shouldn't be NIL */
+Assert(tlist != NIL);
I noticed that I was wrong; in the Assertion the tlist can be empty. An
example for such
On 2016/11/22 18:28, Ashutosh Bapat wrote:
The comments should explain why is the assertion true.
+/* Shouldn't be NIL */
+Assert(tlist != NIL);
I noticed that I was wrong; in the Assertion the tlist can be empty. An
example for such a case is:
SELECT 1 FROM (SELECT c1 FROM
On 2016/11/24 18:20, Ashutosh Bapat wrote:
I wrote:
You missed the point; the foreignrel->reltarget->exprs doesn't contain
any
PHVs, so the tlist created by build_tlist_to_depase will be guaranteed to
be
one-to-one with the foreignrel->reltarget->exprs.
You wrote:
It's guaranteed now, but can
>
>
build_tlist_to_depase() calls pull_var_nodes() before creating the
tlist, whereas the code that searches does not do that. Code-wise
those are not the same things.
>
>
>>> You missed the point; the foreignrel->reltarget->exprs doesn't contain
>>> any
>>> PHVs, so the tlist create
On 2016/11/24 17:39, Ashutosh Bapat wrote:
On Thu, Nov 24, 2016 at 1:27 PM, Etsuro Fujita
wrote:
On 2016/11/24 16:46, Ashutosh Bapat wrote:
table will be misleading as subquery can represent a join and
corresponding alias would represent the join. Relation is better term.
But the documentat
On Thu, Nov 24, 2016 at 1:27 PM, Etsuro Fujita
wrote:
> On 2016/11/24 16:46, Ashutosh Bapat wrote:
Sorry. I think the current version is better than previous one. The
term "subselect alias" is confusing in the previous version. In the
current version, "Get the relation and colu
On 2016/11/24 16:46, Ashutosh Bapat wrote:
Sorry. I think the current version is better than previous one. The
term "subselect alias" is confusing in the previous version. In the
current version, "Get the relation and column alias for a given Var
node," we need to add word "identifiers" like "Get
>
>> Sorry. I think the current version is better than previous one. The
>> term "subselect alias" is confusing in the previous version. In the
>> current version, "Get the relation and column alias for a given Var
>> node," we need to add word "identifiers" like "Get the relation and
>> column ide
On 2016/11/23 0:30, Ashutosh Bapat wrote:
You wrote:
The comment below says "get the aliases", but what the function really
returns
is the identifiers used for creating aliases. Please correct the comment.
+/*
+ * Get the relation and column alias for a given Var node, which belongs
to
+ * input
>
>
>> There is a already a function to build targetlist for a given relation
>> build_tlist_to_deparse(), which does the same thing as this code for a
>> join or
>> base relation and when there are no local conditions. Why don't we use
>> that
>> function instead of duplicating that logic? If tomo
On 2016/11/22 18:28, Ashutosh Bapat wrote:
The comments should explain why is the assertion true.
+/* Shouldn't be NIL */
+Assert(tlist != NIL);
+/* Should be same length */
+Assert(list_length(tlist) ==
list_length(foreignrel->reltarget->exprs));
Will revise.
The comments should explain why is the assertion true.
+/* Shouldn't be NIL */
+Assert(tlist != NIL);
+/* Should be same length */
+Assert(list_length(tlist) ==
list_length(foreignrel->reltarget->exprs));
>
> OK, I'd like to propose referencing to foreignrel->relta
On 2016/11/21 22:02, Ashutosh Bapat wrote:
You wrote:
Instead we should calculate tlist, the
first time we need it and then add it to the fpinfo.
I wrote:
Having said that, I agree on that point. I'd like to propose (1) adding a
new member to fpinfo, to store a list of output Vars from the s
>
> Yeah, I modified the patch so, as I thought that would be consistent with
> the aggregate pushdown patch.
aggregate pushdown needs the tlist to judge the shippability of
targetlist. For joins that's not required, so we should defer, if we
can.
>
>>> Instead we should calculate tlist, the
>>>
On 2016/11/19 0:16, Ashutosh Bapat wrote:
Also another point
I guess, this note doesn't add much value in the given context.
Probably we should remove it.
+* Note: the tlist would have one-to-one correspondence with the
+* joining relation's reltarget->exprs because (1) t
Also another point
I guess, this note doesn't add much value in the given context.
Probably we should remove it.
+* Note: the tlist would have one-to-one correspondence with the
+* joining relation's reltarget->exprs because (1) the above test
+* on PHVs guarant
>
> /*
> * For a join relation or an upper relation, use
> deparseExplicitTargetList.
> * Likewise, for a base relation that is being deparsed as a subquery,
> in
> * which case the caller would have passed tlist that is non-NIL, use
> that
> * function. Otherwise, use depa
On 2016/11/16 18:14, Ashutosh Bapat wrote:
(1) You added the
following comments to deparseSelectSql:
+ /*
+* For a non-base relation, use the input tlist. If a base relation
is
+* being deparsed as a subquery, use input tlist, if the caller has
passed
+* one. The co
Thanks.
> except for few things; (1) You added the
> following comments to deparseSelectSql:
>
> + /*
> +* For a non-base relation, use the input tlist. If a base relation
> is
> +* being deparsed as a subquery, use input tlist, if the caller has
> passed
> +* one. Th
On 2016/11/11 20:50, Etsuro Fujita wrote:
On 2016/11/11 19:22, Ashutosh Bapat wrote:
The patch looks in good shape now. Here are some comments. I have also
made several changes to comments correcting grammar, typos, style and
at few places logic. Let me know if the patch looks good.
OK, will
On 2016/11/11 19:22, Ashutosh Bapat wrote:
The patch looks in good shape now.
Thanks for the review!
The patch looks in good shape now. Here are some comments. I have also
made several changes to comments correcting grammar, typos, style and
at few places logic. Let me know if the patch looks
On Mon, Nov 7, 2016 at 5:50 PM, Etsuro Fujita
wrote:
> On 2016/11/07 11:24, Etsuro Fujita wrote:
>>
>> On 2016/11/04 19:55, Etsuro Fujita wrote:
>>>
>>> Attached is an updated version of the patch.
>
>
>> I noticed that I have included an unrelated regression test in the
>> patch. Attached is a p
On 2016/11/07 11:24, Etsuro Fujita wrote:
On 2016/11/04 19:55, Etsuro Fujita wrote:
Attached is an updated version of the patch.
I noticed that I have included an unrelated regression test in the
patch. Attached is a patch with the test removed.
I noticed that I inadvertently removed some
On 2016/11/04 19:55, Etsuro Fujita wrote:
Attached is an updated version of the patch.
I noticed that I have included an unrelated regression test in the
patch. Attached is a patch with the test removed.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgres
On 2016/11/04 13:08, Ashutosh Bapat wrote:
On Fri, Nov 4, 2016 at 9:19 AM, Etsuro Fujita
wrote:
On 2016/11/03 18:52, Ashutosh Bapat wrote:
I wrote:
Here is the updated version,
Other than the above issue and the alias issue we discussed, I addressed
all
your comments except one on testing
On Fri, Nov 4, 2016 at 9:19 AM, Etsuro Fujita
wrote:
> On 2016/11/03 18:52, Ashutosh Bapat wrote:
>>>
>>> Here is the updated version, which includes the restructuring you
>>> proposed.
>>> Other than the above issue and the alias issue we discussed, I addressed
>>> all
>>> your comments except on
On 2016/11/03 18:52, Ashutosh Bapat wrote:
Here is the updated version, which includes the restructuring you proposed.
Other than the above issue and the alias issue we discussed, I addressed all
your comments except one on testing; I tried to add test cases where the
remote query is deparsed as
> Here is the updated version, which includes the restructuring you proposed.
> Other than the above issue and the alias issue we discussed, I addressed all
> your comments except one on testing; I tried to add test cases where the
> remote query is deparsed as nested subqueries, but I couldn't bec
On 2016/10/27 20:41, Etsuro Fujita wrote:
Here is the updated version, which includes the restructuring you
proposed. Other than the above issue and the alias issue we discussed,
I addressed all your comments except one on testing; I tried to add test
cases where the remote query is deparsed as
On 2016/10/27 18:06, Ashutosh Bapat wrote:
On Thu, Oct 27, 2016 at 12:46 PM, Etsuro Fujita
wrote:
On 2016/10/26 19:53, Ashutosh Bapat wrote:
On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita
My concern about your proposal is: it might not be worth complicating the
code to solve a problem that
On Thu, Oct 27, 2016 at 12:46 PM, Etsuro Fujita
wrote:
> On 2016/10/26 19:53, Ashutosh Bapat wrote:
>>
>> On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita
>> wrote:
>
>
>>> In practice, the search cost would be negligible compared to the cost of
>>> explaining/executing the query.
>>>
>>> My concer
On 2016/10/26 19:53, Ashutosh Bapat wrote:
On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita
wrote:
In practice, the search cost would be negligible compared to the cost of
explaining/executing the query.
My concern about your proposal is: it might not be worth complicating the
code to solve a
On Wed, Oct 26, 2016 at 3:35 PM, Etsuro Fujita
wrote:
> On 2016/10/26 18:25, Ashutosh Bapat wrote:
>
>> Your patch calls isSubqueryExpr() recursively for every Var in the
>> targetlist, which can be many for foreign tables with many columns.
>> For every such Var it may need to reach upto the rela
On 2016/10/26 18:25, Ashutosh Bapat wrote:
Your patch calls isSubqueryExpr() recursively for every Var in the
targetlist, which can be many for foreign tables with many columns.
For every such Var it may need to reach upto the relation which is
converted into subquery, which can as bad as reachi
>
I guess, the arrays need to be
computed only once for any relation when the query for that relation
is deparsed the first time.
>
>
>>> Does this algorithm extend to the case where we consider paths for every
>>> join order?
>
>
>> Yes, if we store the information about which of re
On 2016/10/26 16:11, Ashutosh Bapat wrote:
You wrote:
For
example, let's assume that a relation (1, 2, 3) is required to be
deparsed as subquery for an immediate upper relation (1, 2, 3, 4, 5)
(thus the other joining relation being (4,5)). While deparsing for
relation (1,2,3,4,5), the context wi
>
>
>> For every relation that is deparsed as a subquery, we will create a
>> separate context. Each such context will have an array described
>> above. This array will contain the targetlist and aliases for all the
>> relations, covered by that relation, that are required to be deparsed
>> as subq
On 2016/10/25 18:58, Ashutosh Bapat wrote:
You wrote:
13. The comment below is missing the main purpose i.e. creating a a unique
alias, in case the relation gets converted into a subquery. Lowest or
highest
relid will create a unique alias at given level of join and that would be
more
future pro
>
>> 13. The comment below is missing the main purpose i.e. creating a a unique
>> alias, in case the relation gets converted into a subquery. Lowest or
>> highest
>> relid will create a unique alias at given level of join and that would be
>> more
>> future proof. If we decide to consider paths fo
On 2016/10/22 17:19, Ashutosh Bapat wrote:
Review for postgres-fdw-more-full-join-pushdown-v6 patch.
The patch applies cleanly and regression is clean (make check in
regress directory and that in postgres_fdw).
Thanks for the review!
Here are some comments.
1. Because of the following code c
> 11. I have reworded following comment and restructured the code that follows
> it
> in the attached patch.
> +/*
> + * Set the subquery information. If the relation performs a full outer
> + * join and if the input relations have non-NIL remote_conds, the input
> + * relations n
Review for postgres-fdw-more-full-join-pushdown-v6 patch.
The patch applies cleanly and regression is clean (make check in
regress directory and that in postgres_fdw).
Here are some comments.
1. Because of the following code change, for a joinrel we might end up using
attrs_used, which will be ga
On 2016/09/28 18:35, Etsuro Fujita wrote:
Attached is an updated version of the patch.
I found a minor bug in that patch; the relation_index added to
PgFdwRelationInfo was defined as Index, but I used the modifier %d to
print that. So, I changed the data type to int. Also, I added a bit
mo
On 2016/09/26 16:30, Etsuro Fujita wrote:
On 2016/09/13 14:17, Ashutosh Bapat wrote:
It won't remain minimal as the number of paths created increases,
increasing the number of times a query is deparsed. We deparse query
every time time we cost a path for a relation with use_remote_estimates
tr
On 2016/09/27 13:33, Ashutosh Bapat wrote:
I wrote:
ISTM that the use of the same RTI for subqueries in multi-levels in a
remote
SQL makes the SQL a bit difficult to read. How about using the
position
of
the join rel in join_rel_list, (more precisely, the position plus
list_length(root->parse->
On Tue, Sep 27, 2016 at 8:48 AM, Etsuro Fujita
wrote:
> On 2016/09/26 20:20, Ashutosh Bapat wrote:
>>
>> On Mon, Sep 26, 2016 at 4:06 PM, Etsuro Fujita
>> wrote:
>>>
>>> On 2016/09/26 18:06, Ashutosh Bapat wrote:
On Mon, Sep 26, 2016 at 1:05 PM, Etsuro Fujita
wrote:
>
>
> ISTM
On 2016/09/26 20:20, Ashutosh Bapat wrote:
On Mon, Sep 26, 2016 at 4:06 PM, Etsuro Fujita
wrote:
On 2016/09/26 18:06, Ashutosh Bapat wrote:
On Mon, Sep 26, 2016 at 1:05 PM, Etsuro Fujita
wrote:
ISTM that the use of the same RTI for subqueries in multi-levels in a
remote
SQL makes the SQL a
On Mon, Sep 26, 2016 at 4:06 PM, Etsuro Fujita
wrote:
> On 2016/09/26 18:06, Ashutosh Bapat wrote:
>>
>> On Mon, Sep 26, 2016 at 1:05 PM, Etsuro Fujita
>> wrote:
>
>
>>> ISTM that the use of the same RTI for subqueries in multi-levels in a
>>> remote
>>> SQL makes the SQL a bit difficult to read.
On 2016/09/26 18:06, Ashutosh Bapat wrote:
On Mon, Sep 26, 2016 at 1:05 PM, Etsuro Fujita
wrote:
ISTM that the use of the same RTI for subqueries in multi-levels in a remote
SQL makes the SQL a bit difficult to read. How about using the position of
the join rel in join_rel_list, (more precis
On Mon, Sep 26, 2016 at 1:05 PM, Etsuro Fujita
wrote:
> On 2016/09/15 15:29, Ashutosh Bapat wrote:
>>
>> On Wed, Sep 14, 2016 at 8:52 PM, Robert Haas
>> wrote:
>
>
>>> 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 anywhe
On 2016/09/15 15:29, Ashutosh Bapat wrote:
On Wed, Sep 14, 2016 at 8:52 PM, Robert Haas wrote:
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.
So +1 for
using the smallest RTI to indicate
On 2016/09/13 14:17, Ashutosh Bapat wrote:
But another concern about the approach of generating an
subselect alias for a path, if needed, at the path creation time
would be that the path might be rejected by add_path, which would
result in totally wasting cycles for generating th
On Wed, Sep 14, 2016 at 8:52 PM, Robert Haas wrote:
> On Tue, Sep 13, 2016 at 11:38 PM, Ashutosh Bapat
> wrote:
>> On Tue, Sep 13, 2016 at 10:28 PM, Robert Haas wrote:
>>> On Tue, Sep 6, 2016 at 9:07 AM, Ashutosh Bapat
>>> wrote:
That's not true with the alias information. As long as we de
On Tue, Sep 13, 2016 at 11:38 PM, Ashutosh Bapat
wrote:
> On Tue, Sep 13, 2016 at 10:28 PM, Robert Haas wrote:
>> On Tue, Sep 6, 2016 at 9:07 AM, Ashutosh Bapat
>> wrote:
>>> That's not true with the alias information. As long as we detect which
>>> relations need subqueries, their RTIs are enou
On Tue, Sep 13, 2016 at 10:28 PM, Robert Haas wrote:
> On Tue, Sep 6, 2016 at 9:07 AM, Ashutosh Bapat
> 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
On Tue, Sep 6, 2016 at 9:07 AM, Ashutosh Bapat
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
>
> 3. I think registerAlias stuff should happen really at the time of
>> creating paths and should be stored in fpinfo. Without that it
>> will be
>> computed every time we deparse the query. This means every time
>> we try
>> to EXPLAIN the query at
On 2016/09/09 21:35, Etsuro Fujita wrote:
On 2016/09/08 19:51, Etsuro Fujita wrote:
On 2016/09/06 22:07, Ashutosh Bapat wrote:
This patch tries to do two things at a time 1. support join pushdown for
FULL join when the joining relations have remote conditions 2. better
support for fetching plac
On 2016/09/08 19:51, Etsuro Fujita wrote:
On 2016/09/06 22:07, Ashutosh Bapat wrote:
This patch tries to do two things at a time 1. support join pushdown for
FULL join when the joining relations have remote conditions 2. better
support for fetching placeholder vars, whole row references and some
On 2016/09/06 22:07, Ashutosh Bapat wrote:
On Fri, Sep 2, 2016 at 3:55 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
On 2016/08/22 15:49, Ashutosh Bapat wrote:
1. deparsePlaceHolderVar looks odd - each of the deparse*
function is
named as deparse + .
On Fri, Sep 2, 2016 at 3:55 PM, Etsuro Fujita
wrote:
> Hi Ashutosh,
>
> On 2016/08/22 15:49, Ashutosh Bapat wrote:
>
>> 1. deparsePlaceHolderVar looks odd - each of the deparse* function is
>> named as deparse + > into>. PlaceHolderVar is not a parser node, so no string is going to be
>> parsed a
Hi Ashutosh,
On 2016/08/22 15:49, Ashutosh Bapat wrote:
1. deparsePlaceHolderVar looks odd - each of the deparse* function is
named as deparse + . PlaceHolderVar is not a parser node, so no string is going to be
parsed as a PlaceHolderVar. May be you want to name it as
deparseExerFromPlaceholder
Thanks Fujita-san for working on this. I took a quick look at the patch.
Here are some quick comments.
1. deparsePlaceHolderVar looks odd - each of the deparse* function is named
as deparse + .
PlaceHolderVar is not a parser node, so no string is going to be parsed as
a PlaceHolderVar. May be you
Hi,
The postgres_fdw join pushdown in 9.6 is great, but it can't handle full
joins on relations with restrictions. The reason for that is,
postgres_fdw can't support deparsing subqueries when creating a remote
join query. So, by adding the deparsing logic to it, I removed that
limitatio
93 matches
Mail list logo