On 2015/09/30 6:55, Robert Haas wrote:
On Mon, Sep 28, 2015 at 11:15 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
I thought the same thing [1]. While I thought it was relatively easy to
make changes to RefetchForeignRow that way for the foreign table case
(scanrelid
On 2015/10/01 19:02, Kyotaro HORIGUCHI wrote:
At Thu, 1 Oct 2015 17:50:25 +0900, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote
in <560cf3d1.9060...@lab.ntt.co.jp>
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
forming the query to
B leftjoin (A leftjoin (C innerjoin D) on Pa) on (Pbcd)
which yields totally wrong answers. We prevent that by forcing the min LHS
for the upper join to include B.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
that that function should fetch the same version
previously obtained for each such relation successfully.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015/10/01 22:31, Tom Lane wrote:
> Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes:
>> The following is a remark added to /src/backend/optimizer/README by
>> commit 8703059c6b55c427100e00a09f66534b6ccbfaa1, and IIUC, I think "LHS"
>> in the last sentenc
On 2015/10/03 5:57, Robert Haas wrote:
On Fri, Oct 2, 2015 at 4:04 AM, Peter Geoghegan <p...@heroku.com> wrote:
On Fri, Oct 2, 2015 at 1:00 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
ISTM that the sentence "as remote constraints are not locally known" is
somew
ther table, there
* doesn't seem to be enough use-case to justify adding a lot of code
* for that.
How about s/best_inner_indexscan()/parameterized scans/?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On 2015/09/29 16:36, Etsuro Fujita wrote:
For the foreign table case (scanrelid>0), I imagined an approach
different than yours. In that case, I thought the issue would be
probably addressed by just modifying the remote query performed in
RefetchForeignRow, which would be of the form &quo
own"? Attached is a
patch for that.
Best regards,
Etsuro Fujita
*** a/doc/src/sgml/fdwhandler.sgml
--- b/doc/src/sgml/fdwhandler.sgml
***
*** 1196,1204 GetForeignServerByName(const char *name, bool missing_ok);
INSERT with an ON CONFLICT clause does not
!
On 2015/10/01 11:15, Kouhei Kaigai wrote:
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
On Mon, Sep 28, 2015 at 11:15 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
I thought the same thing [1]. While I t
the applicability of late
row locking to the foreign join case, allowing component foreign tables
involved in a foreign join to have different rowmark methods other than
ROW_MARK_COPY.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
On 2015/09/29 9:13, Kouhei Kaigai wrote:
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
Sent: Tuesday, September 29, 2015 5:46 AM
To: Kaigai Kouhei(海外 浩平)
Cc: Etsuro Fujita; PostgreSQL-development; 花田茂
can.
Best regards,
Etsuro Fujita
*** a/src/backend/optimizer/plan/setrefs.c
--- b/src/backend/optimizer/plan/setrefs.c
***
*** 1108,1114 set_foreignscan_references(PlannerInfo *root,
if (fscan->fdw_scan_tlist != NIL || fscan->scan.scanrelid == 0)
{
! /* Adjust tlist,
On 2015/12/08 17:27, Ashutosh Bapat wrote:
On Thu, Dec 3, 2015 at 12:36 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
Generating paths
A join between two foreign relations is considered
otherclauses"
(rinfo->is_pushed_down=true) and that 2) were pushed down to the remote
server, not scan quals relevant to all the base tables invoved in the
foreign-join. So in this definition, I think fdw_recheck_quals for a
foreign-join will be workable, regardless of the join type.
On 2015/12/02 14:54, Kouhei Kaigai wrote:
On 2015/12/02 1:41, Robert Haas wrote:
On Thu, Nov 26, 2015 at 7:59 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
The attached patch adds: Path *fdw_outerpath field to ForeignPath node.
FDW driver can set arbitrary but one path-nod
or foreign joins. Corresponding changes to
postgres_fdw
will need to be added once those changes get committed.
Yeah, we would need those changes including helper functions to create a
local join execution plan for that support. I'd like to add those
changes to your updated patch if
ersion of the patch for this is in good shape, but
that would need some changes as proposed on that thread. So, if there
are no objections, I'll update the patch.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 2015/12/05 5:15, Robert Haas wrote:
On Tue, Dec 1, 2015 at 10:20 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
One thing I can think of is that we can keep both the structure of a
ForeignPath node and the API of create_foreignscan_path as-is. The latter
is a good thing f
On 2015/12/09 13:26, Kouhei Kaigai wrote:
On Tue, Dec 8, 2015 at 10:00 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
I think the actual regression test outputs are fine, and that your
desire to suppress part of the plan tree from showing up in the
EXPLAIN output is misguided.
atch.
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml
index 0090e24..dc2d890 100644
--- a/doc/src/sgml/fdwhandler.sgml
+++ b/doc/src/sgml/fdwhandler.sgml
@@ -793,7 +793,7 @@ RecheckForeignScan (ForeignScanState *node, TupleTableSlot *slot);
On 2015/12/09 1:13, Robert Haas wrote:
On Tue, Dec 8, 2015 at 5:49 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
I'd like to discuss the next
thing about his patch. As I mentioned in [1], the following change in
the patch will break the EXPLAIN output.
@@ -205,6 +
On 2015/12/02 1:41, Robert Haas wrote:
On Thu, Nov 26, 2015 at 7:59 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
The attached patch adds: Path *fdw_outerpath field to ForeignPath node.
FDW driver can set arbitrary but one path-node here.
After that, this path-node shall be trans
On 2015/12/02 1:53, Robert Haas wrote:
On Fri, Nov 27, 2015 at 1:33 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote: Plan *plan =
>scan.plan;
@@ -3755,7 +3763,7 @@ make_foreignscan(List *qptlist,
/* cost will be filled in by create_foreignscan_plan */
On 2015/12/11 1:18, Robert Haas wrote:
On Wed, Dec 9, 2015 at 2:52 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
Thank you for committing the patch!
Sorry, I overlooked a typo in docs: s/more that one/more than one/ Please
find attached a patch.
Committed, thanks.
Thanks!
On 2015/12/11 14:16, Ashutosh Bapat wrote:
On Thu, Dec 10, 2015 at 11:20 PM, Robert Haas <robertmh...@gmail.com
<mailto:robertmh...@gmail.com>> wrote:
On Tue, Dec 8, 2015 at 6:40 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>&
On 2016/01/06 20:37, Thom Brown wrote:
On 25 December 2015 at 10:00, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
Attached is an updated version of the patch, which is
still WIP, but I'd be happy if I could get any feedback.
I've run into an issue:
*# UPDATE master_customers
, if any expressions to assign to
the target
+ * columns are unsafe to evaluate on the remote server.
I think this depends on the capabilities of the FDW.
.) Documentation for the new API is missing (fdw-callbacks).
Will add the docs.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers
On 2016/01/07 21:50, Etsuro Fujita wrote:
On 2016/01/06 20:37, Thom Brown wrote:
On 25 December 2015 at 10:00, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
Attached is an updated version of the patch, which is
still WIP, but I'd be happy if I could get any feedback.
I'
RT
.. RETURNING .., but I'd like to leave that for future work.
I'll add this to the next CF.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgres_fdw/deparse.c
***
*** 816,822 deparseTargetList(StringInfo buf,
*
* If params is not N
t regards,
Etsuro Fujita
*** a/src/backend/optimizer/plan/createplan.c
--- b/src/backend/optimizer/plan/createplan.c
***
*** 2097,2106 create_foreignscan_plan(PlannerInfo *root, ForeignPath *best_path,
RelOptInfo *rel = best_path->path.parent;
Index scan_relid = rel-&g
On 2015/11/26 18:00, Etsuro Fujita wrote:
On 2015/11/25 20:36, Thom Brown wrote:
On 13 May 2015 at 04:10, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>
wrote:
On 2015/05/13 0:55, Stephen Frost wrote:
While the EXPLAIN output changed, the structure hasn't really changed
from what was dis
orry, I don't understand this. In my understanding, fdw_recheck_quals
can be defined for a foreign join, regardless of the join type, and when
the fdw_recheck_quals are defined, the RecheckForeignScan callback
routine doesn't need to evaluate the fdw_recheck_quals by itself. No?
Best regards,
Etsuro Fujit
should be mirror images of
each other, but I think that that break would be harmless.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/55def5f0@lab.ntt.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Thom,
Thank you for paying attention to this!
On 2015/11/25 20:36, Thom Brown wrote:
On 13 May 2015 at 04:10, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
On 2015/05/13 0:55, Stephen Frost wrote:
While the EXPLAIN output changed, the structure hasn't really changed
fro
es_fdw to run the alternative sub-plan on EPQ recheck.
Will do.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015/11/19 12:34, Robert Haas wrote:
On Tue, Nov 17, 2015 at 9:30 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
I suppose you (and KaiGai-san) are probably right, but I really fail to see
it actually doing that.
Noted, but let's do it that way and move on. It would be a
On 2015/11/19 5:29, Robert Haas wrote:
On Tue, Nov 17, 2015 at 9:29 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
On 2015/11/18 2:57, Robert Haas wrote:
On Sun, Nov 15, 2015 at 9:25 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
Oops, I've found another one.
missing
something, but what use cases are you thinking?
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/55af3c08.1070...@lab.ntt.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015/11/20 6:57, Robert Haas wrote:
On Wed, Nov 18, 2015 at 10:54 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
Noted, but let's do it that way and move on. It would be a shame if
we didn't end up with a working FDW join pushdown system in 9.6
because of a disagr
egards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
and evaluate the
otherclauses as part of the local join execution plan, so that
fdw_scan_tlist won't end up being longer, as in the patch [1]. (Note
that in that patch, remote_exprs==NIL when calling make_foreignscan
during postgresGetForeignPlan in case of foreign joins.)
Best regards,
Etsuro Fuj
On 2015/11/09 9:26, Kouhei Kaigai wrote:
The attached patch is an adjusted version of the previous one.
There seems to be no changes to make_foreignscan. Is that OK?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
e a good idea. Will update the patch.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2016/01/07 21:45, Etsuro Fujita wrote:
On 2016/01/06 18:58, Rushabh Lathia wrote:
.) Documentation for the new API is missing (fdw-callbacks).
Will add the docs.
I added docs for new FDW APIs.
Other changes:
* Rename relation_has_row_level_triggers to relation_has_row_triggers
On 2016/01/12 20:36, Thom Brown wrote:
On 8 January 2016 at 05:08, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
On 2016/01/06 20:37, Thom Brown wrote:
I've run into an issue:
*# UPDATE master_customers SET id = 22 WHERE id = 16 RETURNING
tableoid::regclass;
ERROR:
CONTEXT: Remo
On 2016/05/27 8:49, Michael Paquier wrote:
On Thu, May 26, 2016 at 4:25 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
Honestly, I didn't have any idea for executing such an insert efficiently,
but I was thinking to execute an insert into a foreign table efficiently, by
s
On 2016/05/17 0:25, Robert Haas wrote:
On Wed, May 11, 2016 at 3:20 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
Thanks for the review!
I'll add this to the next CF. I think this should be addressed in advance
of the release of 9.6, though.
I agree. Committed.
Thanks!
, 5, 6) or
INSERT INTO foreign_table(a,b,c) SELECT a,b,c FROM foreign_table2
where foreign_table and foreign_table2 belong to the same foreign
server, then we could send the whole insert to the remote server.
Wouldn't that make sense?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers m
On 2016/05/31 14:53, Amit Langote wrote:
On 2016/05/30 22:59, Craig Ringer wrote:
On 30 May 2016 at 16:17, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
That's a good point, but the basic idea is to send the local query
almost-as-is to the remote server if possible. For e
On 2016/06/22 18:16, Ashutosh Bapat wrote:
On Wed, Jun 22, 2016 at 2:26 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
I think we could address this in another way once we support
deparsing subqueries; rewrite the
For the CASE WHEN conversion for a system column other than ctid, we
could also address this by replacing the whole-row reference in the IS
NOT NULL condition in that conversion with the system column reference.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
inner join ft2 on ft1.a =
ft2.a) left join ft3 on ft1.a = ft3.a
Right?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t;CASE
WHEN r1.ctid IS NOT NULL THEN ROW(r1.empno, r1.ename, r1.job, r1.mgr,
r1.hiredate, r1.sal, r1.comm, r1.deptno) END". IMO I think that that
would be much simpler than Ashutosh's approach.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
f them are available.
You are right. Sorry for the noise.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2016/06/16 22:00, Robert Haas wrote:
On Thu, Jun 16, 2016 at 7:05 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
ISTM that a robuster solution to this is to push down the ft1-ft2-ft3 join
with the PHV by extending deparseExplicitTargetList() and/or something else
so that we ca
On 2016/06/22 19:37, Ashutosh Bapat wrote:
On Wed, Jun 22, 2016 at 3:57 PM, Etsuro Fujita
Maybe I'm confused, but I think that in the system-column case it's
the user's responsibility to specify system columns for foreign
tables in a local query only when that makes sense
Attached patch makes minor modification to the GetForeignPlan
documentation. This adds the description about outer_plan, the new
parameter added in 9.5.
Best regards,
Etsuro Fujita
*** a/doc/src/sgml/fdwhandler.sgml
--- b/doc/src/sgml/fdwhandler.sgml
***
*** 178,184
On 2015/12/11 2:21, Robert Haas wrote:
On Tue, Dec 8, 2015 at 6:16 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
Attached is a small patch to adjust a comment in setrefs.c; in
set_foreignscan_references, fdw_recheck_quals also gets adjusted to
reference foreign scan tuple, i
On 2016/01/12 20:31, Rushabh Lathia wrote:
On Thu, Jan 7, 2016 at 6:15 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
On 2016/01/06 18:58, Rushabh Lathia wrote:
.) What the need of following change ?
@@ -
s in
case a system column appears in the joinclauses it will not be considered.
IIUC, we assume that such system columns are assumed to be contained in
fdw_scan_tlist in the joinrel case.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On 2016/01/12 18:00, Etsuro Fujita wrote:
On 2016/01/12 2:36, Alvaro Herrera wrote:
I wonder,
--- 2166,2213
}
/*
! * If rel is a base relation, detect whether any system columns
are
! * requested from the rel. (If rel is a join relation,
rel->re
On 2016/01/08 14:08, Etsuro Fujita wrote:
On 2016/01/07 21:50, Etsuro Fujita wrote:
On 2016/01/06 20:37, Thom Brown wrote:
I've run into an issue:
*# UPDATE master_customers SET id = 22 WHERE id = 16 RETURNING
tableoid::regclass;
ERROR:
CONTEXT: Remote SQL command: UPDATE public.customers
).
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2016/01/15 19:00, Etsuro Fujita wrote:
On 2016/01/12 18:00, Etsuro Fujita wrote:
On 2016/01/12 2:36, Alvaro Herrera wrote:
I wonder,
--- 2166,2213
}
/*
! * If rel is a base relation, detect whether any system columns
are
! * requested from the rel. (If rel
should read "whole row reference of
foreign table ft1".
OK, attached is an updated version of the patch, which uses "whole-row
reference", not "wholerow".
Best regards,
Etsuro Fujita
postgres-fdw-conv-error-callback-v3.patch
Description: binary/octet-stream
--
On 2016/06/27 18:56, Ashutosh Bapat wrote:
On Mon, Jun 27, 2016 at 3:06 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
I found another bug in error handling of whole-row references in
join pushdown; conversion_error_callback f
an updated version.
Best regards,
Etsuro Fujita
postgres-fdw-conv-error-callback-v4.patch
Description: binary/octet-stream
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Here is a patch to use %u not %d to print umid and userid.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/connection.c
--- b/contrib/postgres_fdw/connection.c
***
*** 159,165 GetConnection(UserMapping *user, bool will_prep_stmt)
entry->have_error = false;
en
k executed should succeed.) The reason for that is that the
targetlist of the local join plan is the same as for the ForeignScan,
which outputs neither foo.a nor bar.a required as an argument of the
function add().
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On 2016/02/04 17:58, Etsuro Fujita wrote:
On 2016/02/04 8:00, Robert Haas wrote:
On Wed, Feb 3, 2016 at 5:56 PM, Robert Haas <robertmh...@gmail.com>
wrote:
On Wed, Feb 3, 2016 at 12:08 PM, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
PFA patches with naming convent
think the patch fails to adjust the targetlist of the top
plan created that way, to output the fdw_scan_tlist, as discussed in [1]
(ie, I think the attached patch is needed, which is created on top of
your patch pg_fdw_join_v8.patch).
Best regards,
Etsuro Fujita
[1]
http://www.postgre
of the patch. You don't need to apply the patch
fdw-foreign-modify-rmh-v2.patch attached before.
Thanks for the review!
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgres_fdw/deparse.c
***
*** 1069,1074 deparseUpdateSql(StringInfo buf
licating the docs.
Also:
"When the query doesn't has the clause, the FDW must also increment
the row count for the ForeignScanState node in the EXPLAIN ANALYZE
case."
Should read "doesn't have"
Will fix.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list
postgresBeginForeignScan and
postgresBeginForeignModify can call.
execute_dml_stmt() has some of the same disease.
Will do.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
xecuted, thus even if root->rowMarks is NIL, EPQ
check can fire and we will need alternate local plan.
Yeah, I think that is true, but if root->rowMarks==NIL, we won't have
non-target foreign tables, and therefore postgresGetForeignJoinPaths()
will never be called. No?
Best regards,
Etsur
-foreign-join-path cases,
though that would work well for the unparameterized-foreign-join-path
cases. We don't support parameterized-foreign-join paths for 9.6?
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/5666b59f.6010...@lab.ntt.co.jp
--
Sent via pgsql-hackers
lUpdatable discussed
above reports not only the updatability but the insertability and
deletability of a foreign table!). So, +1 for leaving that as-is.
Apart from this perform sanity testing on the new patch and things working
as expected.
Thanks for the review!
Best regards,
Etsuro Fujita
?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2016/01/28 15:20, Rushabh Lathia wrote:
On Thu, Jan 28, 2016 at 11:33 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
On 2016/01/27 21:23, Rushabh Lathia wrote:
If I understood correctly, above documentation means, that if
On 2016/01/28 12:13, Robert Haas wrote:
On Thu, Jan 21, 2016 at 5:55 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
On 2016/01/21 7:04, Alvaro Herrera wrote:
Etsuro Fujita wrote:
On second thought, I noticed that detecting whether we see a system
column
that way needs more
On 2016/01/28 12:58, Robert Haas wrote:
On Thu, Jan 21, 2016 at 4:05 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
By the way, I'm not too sure I understand the need for the core
changes that are part of this patch, and I think that point merits
some discussion. Whenever you
On 2016/01/28 18:15, Alvaro Herrera wrote:
Etsuro Fujita wrote:
On 2016/01/28 12:13, Robert Haas wrote:
I don't think this is a good idea. Most of the time, no system
columns will be present, and we'll just be scanning the Bitmapset
twice rather than once. Sure, that doesn't take many
columns,
but the
I don't think the data is referenced by the AFTER ROW DELETE triggers.
Attached is a patch to fix that. The patch also avoids adding an
unnecessary RETURNING clause to DELETE when deparsing a remote DELETE
statement in postgres_fdw.
I'll add this to the next CF.
Best regards,
Etsuro
On 2016/01/28 15:20, Rushabh Lathia wrote:
On Thu, Jan 28, 2016 at 11:33 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
On 2016/01/27 21:23, Rushabh Lathia wrote:
If I understood correctly, above documentation means, that if
On 2016/02/04 12:04, Robert Haas wrote:
On Wed, Feb 3, 2016 at 10:00 PM, Noah Misch <n...@leadboat.com> wrote:
Thank you.
+1.
Thank you!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 2016/02/04 0:13, Robert Haas wrote:
On Mon, Feb 1, 2016 at 5:26 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
I don't think the data is referenced by the AFTER ROW DELETE triggers.
Why do you think that? And why would DELETE triggers be different
from UPDATE triggers, wh
On 2016/01/29 17:52, Ashutosh Bapat wrote:
On Fri, Jan 29, 2016 at 2:05 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
On 2016/01/29 1:26, Ashutosh Bapat wrote:
Here is the summary of changes from the last set of patches
h;
+ }
* IIUC, that function will be used by custom joins, so I think it would
be better to put that function somewhere in the /optimizer directory
(pathnode.c?).
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On 2016/02/03 3:31, Alvaro Herrera wrote:
Etsuro Fujita wrote:
Done. Attached is an updated version of the patch.
Pushed, thanks.
Thank you!
I kinda wonder why this struct member has a name that doesn't match the
naming convention in the rest of the struct, and also why isn't
e PostgreSQL project.
Congratulations, Dean. Well deserved.
Congratulations, Dean!
Congratulations!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2016/02/22 20:13, Rushabh Lathia wrote:
I did another round of review for the latest patch and well as performed
the sanity test, and
haven't found any functional issues. Found couple of issue, see in-line
comments
for the same.
Thanks!
On Thu, Feb 18, 2016 at 3:15 PM, Etsuro Fujita
On 2016/01/21 7:04, Alvaro Herrera wrote:
Etsuro Fujita wrote:
On second thought, I noticed that detecting whether we see a system column
that way needs more cycles in cases where the reltargetlist and the
restriction clauses don't contain any system columns. ISTM that such cases
are rather
On 2016/01/21 5:06, Robert Haas wrote:
On Wed, Jan 20, 2016 at 4:50 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
My concern about that is that would make the code in deparseTargetList()
complicated.
Essentially, I think your propossal needs a two-pass algorithm for
deparseTarg
a fix for a wrong copy-and-paste.
Best regards,
Etsuro Fujita
[1]
http://www.postgresql.org/message-id/ca+tgmoz40j2uc5ac1nxu03oj4crvolks15xx+ptfp-1u-8z...@mail.gmail.com
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgres_fdw/deparse.c
***
*** 823,829 deparseTargetList
On 2016/01/19 19:04, Thom Brown wrote:
On 12 January 2016 at 11:49, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
On 2016/01/12 20:36, Thom Brown wrote:
On 8 January 2016 at 05:08, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>
wrote:
On 2016/01/06 20:37, Thom Brown wrote
On 2016/01/26 22:57, Rushabh Lathia wrote:
On Tue, Jan 26, 2016 at 4:15 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
On 2016/01/25 17:03, Rushabh Lathia wrote:
int
IsForeignRelUpdatable (
On 2016/01/20 3:42, Robert Haas wrote:
On Tue, Jan 19, 2016 at 1:59 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
I've run into an issue:
*# UPDATE master_customers SET id = 22 WHERE id = 16 RETURNING
tableoid::regclass;
ERROR:
CONTEXT: Remote SQL command: UPDATE public.custome
Here is a small patch to do s/for/For/ to two section titles in
fdwhandlers.sgml, for consistency.
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml
index dc2d890..9c8406c 100644
--- a/doc/src/sgml/fdwhandler.sgml
+++ b/doc/src/sgml
On 2016/01/27 12:20, Etsuro Fujita wrote:
On 2016/01/26 22:57, Rushabh Lathia wrote:
On Tue, Jan 26, 2016 at 4:15 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
On 2016/01/25 17:03, Rushabh Lathia wrote:
501 - 600 of 949 matches
Mail list logo
