.
1459 */
So, I've updated the comments. Please find attached a patch.
Best regards,
Etsuro Fujita
*** a/src/backend/optimizer/util/pathnode.c
--- b/src/backend/optimizer/util/pathnode.c
***
*** 1449,1459 create_worktablescan_path(PlannerInfo *root, RelOptInfo *rel
Hi,
I'm attaching a small patch to fix another comment typo in setrefs.c:
s/TIDs/OIDs/
Best regards,
Etsuro Fujita
diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c
index ee8710d..093d925 100644
--- a/src/backend/optimizer/plan/setrefs.c
+++ b/src/backend
after a bit of research into when things actually changed.
Awesome, thanks!
Thank you, Stephen and Tom.
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/09/11 6:24, Robert Haas wrote:
On Thu, Sep 3, 2015 at 1:22 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
I'm wondering if there's another approach. If I understand correctly,
there are two reasons why the current situation is untenable. The
first is that ForeignRecheck
On 2015/09/09 3:53, Robert Haas wrote:
On Tue, Sep 8, 2015 at 5:35 AM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
On 2015/09/04 0:33, Robert Haas wrote:
I'm worried that trawling through that
SpecialJoinInfo data will end up needing to duplicate much of
make_jo
On 2015/07/10 18:40, Etsuro Fujita wrote:
> To save cycles, I modified create_foreignscan_plan so that it detects
> whether any system columns are requested if scanning a base relation.
> Also, I revised other code there a little bit.
Attached is an updated version of the patch. The
g
bigft1 and bigft2 locally, I think that the FDW could find that it's
sensible to generate the foreign-join path for (bigft1, bigft2) with the
parameterization.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
On 2015/09/02 23:30, Tom Lane wrote:
> Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> writes:
>> On 2015/08/01 23:25, Tom Lane wrote:
>>> In my vision you probably really only want one call per build_join_rel
>>> event (that is, per construction of a new RelOptInfo)
On 2015/09/04 19:50, Etsuro Fujita wrote:
I'm attaching an updated version of the patch. The patch is based on
the SS_finalize_plan patch that has been recently committed. I'd be
happy if this helps people discuss more about how to fix this issue.
In the updated version, I modified
On 2015/09/03 19:25, Etsuro Fujita wrote:
On 2015/09/03 14:22, Etsuro Fujita wrote:
On 2015/09/03 9:41, Robert Haas wrote:
That having been said, I don't entirely like Fujita-san's patch
either. Much of the new code is called immediately adjacent to an FDW
callback which could pretty
On 2015/09/03 14:22, Etsuro Fujita wrote:
On 2015/09/03 9:41, Robert Haas wrote:
That having been said, I don't entirely like Fujita-san's patch
either. Much of the new code is called immediately adjacent to an FDW
callback which could pretty trivially do the same thing itself, if
needed
,
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/09/02 15:40, Amit Langote wrote:
On 2015-09-02 PM 03:25, Amit Kapila wrote:
On Wed, Sep 2, 2015 at 11:35 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>
The UPDATE/DELETE pushdown, which I've proposed, would ensure the sane
behaviour for inherited UPDATEs/DELETEs, as existi
o avoid needless
deadlocks.
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
n join (or just doing ExecQual for checking remote quals in case
of foreign table), I'd agree with introducing the callback, but if not,
I don't think that that makes much sense.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
that will be difficult for application to decide and then it
needs to decide the same for all statements which is tricky because
different statements could take different time. I think it is better to
have solution for this problem and deadlock should be detected.
+1
Best regards,
Etsuro Fujita
--
oreign server, for example, we can
skip the routine's work if the join rel proved to be joined with C on
the same foreign server by looking at rel->joininfo, for example.)
Maybe I'm missing something, though.
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
it's worth, could be 6 times faster for an "average" sized
table, but hey, we're talking nanoseconds anyway...
That's interesting. But ISTM that that needs more discussion, so I'd
like to leave the method as-is at least for now.
Thanks for the experiment!
Best regards,
Ets
are performed by first fetching
records from the table scanning functions, and then going over
the fetched records. If the user wanted to update a single row,
this involved first pulling rows and then updating related
records.
Best regards,
Etsuro Fujita
[1] https
On 2015/07/22 15:25, Etsuro Fujita wrote:
On 2015/07/10 21:59, David Rowley wrote:
On 10 July 2015 at 21:40, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
mailto:fujita.ets...@lab.ntt.co.jp wrote:
To save cycles, I modified create_foreignscan_plan so that it detects
whether any system
On 2015/08/27 17:30, Etsuro Fujita wrote:
I think we would probably need others' opinions about this issue.
Attached is an updated version of the patch [1]. I'd be happy if it
helps people discuss about this issue.
Changes:
* rebased to HEAD.
* add some more docs and comments.
* fix a bug
to an internal
change in the core, unless there is a good reason or use-case for that.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/55cb2d45.7040...@lab.ntt.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
the patch in [1] and add it to the
upcoming CF.
It seems to me too invasive for bugfix, and assumes a particular solution.
Please do the rechecking part in the extension, not in the core.
I think we would probably need others' opinions about this issue.
Best regards,
Etsuro Fujita
--
Sent via
be an idea, but I'd like to hear the opinions of others.
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
.
No, I just want to know the need or advantage for that specifically.
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
implementing their own EPQ would be subject to an internal change in the
core.
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
so, in
practice because I think EPQ testing is only execute a subplan for a
*single* set of component test tuples. Maybe I'm missing something, though.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
,
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
])
add_GetUserMappingById.patch (in [3])
foreign_join_v16_efujita.patch
(Note that you cannot do tests of [1]. For that, apply
fdw-eval-plan-qual-0.1.patch and the postgres_fdw patch in [1] in this
order.)
Comments welcome!
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id
dicussed in [1] first because I
think that would affect the design of join pushdown API in the core.
I'll submit a patch for that within a few days. I'd like to review this
in detail after addressing that, if it's OK.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id
On 2015/07/07 19:15, Etsuro Fujita wrote:
On 2015/07/06 9:42, Kouhei Kaigai wrote:
However, we need to pay attention on advantages towards the alternatives.
Hooks on add_paths_to_joinrel() enables to implement identical stuff,
with
less complicated logic to reproduce left / right relations from
On 2015/07/27 18:16, Kouhei Kaigai wrote:
On 2015/07/24 23:51, Kouhei Kaigai wrote:
On 2015/07/22 19:10, Etsuro Fujita wrote:
While working on the issue Foreign join pushdown vs EvalPlanQual, I
happened to notice odd behaviors of late row locking in FDWs.
I think the reason
KaiGai-san,
On 2015/07/24 23:51, Kouhei Kaigai wrote:
On 2015/07/22 19:10, Etsuro Fujita wrote:
While working on the issue Foreign join pushdown vs EvalPlanQual, I
happened to notice odd behaviors of late row locking in FDWs.
I think the reason for that is because we don't check pushed-down
On 2015/07/22 19:10, Etsuro Fujita wrote:
While working on the issue Foreign join pushdown vs EvalPlanQual, I
happened to notice odd behaviors of late row locking in FDWs.
I think the reason for that is because we don't check pushed-down quals
inside an EPQ testing even if what was fetched
On 2015/07/10 21:59, David Rowley wrote:
On 10 July 2015 at 21:40, Etsuro Fujita fujita.ets...@lab.ntt.co.jp
mailto:fujita.ets...@lab.ntt.co.jp wrote:
To save cycles, I modified create_foreignscan_plan so that it detects
whether any system columns are requested if scanning a base
, but I have a similar
concern for the simple-custom-scan case too.
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/07/21 1:38, Alvaro Herrera wrote:
Etsuro Fujita wrote:
I ran into a typo in a comment in setrefs.c. Patch attached.
Fixed by Heikki in 7845db2aa.
Thank you for letting me know about that, Alvaro! And thanks Heikki for
picking this up!
Best regards,
Etsuro Fujita
--
Sent via
regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/16016.1431455...@sss.pgh.pa.us
*** a/contrib/postgres_fdw/connection.c
--- b/contrib/postgres_fdw/connection.c
***
*** 384,390 begin_remote_xact(ConnCacheEntry *entry)
if (IsolationIsSerializable())
sql = START
you mean. Maybe I have to learn more
about custom scans/joins, but thanks for the explanation!
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
to propose a patch for the issue Foreign join pushdown vs
EvalPlanQual, but I need more time ...
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
complex beyound necessity. Maybe
that might be nitpicking, though.
Best regards,
Etsuro Fujita
*** a/src/backend/executor/nodeForeignscan.c
--- b/src/backend/executor/nodeForeignscan.c
***
*** 159,182 ExecInitForeignScan(ForeignScan *node, EState *estate, int eflags
EXPLAINs for A-B, A-C and B-C seem to me meaningless while incurring
performance degradation in query planning. Maybe I'm missing something,
though.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
important to ensure the expandability, and my
question is, is it possible that the API call from standard_join_search
also realize those idea if FDWs can get the join information through the
root or something like that?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql
by a for update;
[Terminal 1]
postgres=# commit;
COMMIT
[Terminal 2]
(The following result will be shown after the commit in Terminal 1.
Note that the output ordering is not correct.)
a
---
3
2
(2 rows)
Best regards,
Etsuro Fujita
*** a/src/backend/executor/nodeLockRows.c
--- b/src/backend
Hi Marko,
On 2015/07/02 16:27, Marko Tiikkaja wrote:
On 7/2/15 9:15 AM, Etsuro Fujita wrote:
While working on the foreign-join-pushdown issue, I noticed that in READ
COMMITTED isolation level it's possible that the result of SELECT ...
ORDER BY ... FOR UPDATE is not sorted correctly due
-san, are you available to make a patch with this approach?
If so, I'd like to volunteer its reviewing.
Yeah, I'm willing to make a patch if we obtain the consensus! And I'd
be happy if you help me doing the work!
Best regards,
Etsuro Fujita
[2] http://www.postgresql.org/message-id
that that is a good idea, but anyway, I think we need to
hurry fixing this issue.
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
path in the local. That would also allow FDW
authors to write the foreign join pushdown functionality in their FDWs
by smaller efforts.
Best regards,
Etsuro Fujita
[1]
http://www.postgresql.org/message-id/CAEZqfEe9KGy=1_wagh2rgzpg0o4pqgd+iauyaj8wtze+cyj...@mail.gmail.com
--
Sent via pgsql
late row locking using the
postgres_fdw.
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
regards,
Etsuro Fujita
[1]
http://www.postgresql.org/message-id/CAEZqfEe9KGy=1_wagh2rgzpg0o4pqgd+iauyaj8wtze+cyj...@mail.gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I ran into a typo in a comment in setrefs.c. Patch attached.
Best regards,
Etsuro Fujita
diff --git a/src/backend/optimizer/plan/setrefs.c b/src/backend/optimizer/plan/setrefs.c
index a7f65dd..162a52e 100644
--- a/src/backend/optimizer/plan/setrefs.c
+++ b/src/backend/optimizer/plan/setrefs.c
confusing
because I think typed tables cannot inherit. Maybe I'm missing
something though. Proposed patch attached.
Best regards,
Etsuro Fujita
*** a/src/backend/commands/tablecmds.c
--- b/src/backend/commands/tablecmds.c
***
*** 9853,9862 ATExecEnableDisableRule(Relation rel, char
On 2015/06/05 6:51, Robert Haas wrote:
On Mon, Jun 1, 2015 at 10:44 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Here is a doc patch to add materialized views and foreign tables to
database objects that pg_table_is_visible() can be used with.
Good catch, as usual. Committed.
Thanks
Hi,
Here is a doc patch to add materialized views and foreign tables to
database objects that pg_table_is_visible() can be used with.
Best regards,
Etsuro Fujita
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***
*** 15537,15544 SELECT relname FROM pg_class WHERE
On 2015/05/22 23:50, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
I agree with you on that point. And I think one option for that is that
IMPORT FOREIGN SCHEMA only imports CHECK constraints of remote tables
from a remote server that have convalidated = true. (If doing
On 2015/05/26 3:15, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
On 2015/05/22 23:50, Tom Lane wrote:
So I think worrying about convalidated is pretty pointless. Really,
it is up to the user to determine what constraints should be attached
to the foreign table, and IMPORT
Hi,
The attached patch fixes a typo in a comment in tablecmds.c.
Best regards,
Etsuro Fujita
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 33ea387..5114e6f 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend/commands/tablecmds.c
@@ -2342,7
On 2015/05/20 22:59, Heikki Linnakangas wrote:
On 05/20/2015 12:40 PM, Etsuro Fujita wrote:
The attached patch fixes a typo in a comment in tablecmds.c.
Fixed, along with dozens more similar typos I found with some grepping.
Thanks for doint that completely!
Best regards,
Etsuro Fujita
On 2015/05/16 3:46, Robert Haas wrote:
On Thu, May 14, 2015 at 4:07 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
The attached patch adds missing NO INHERIT to the CHECK clause in the
synopsis section in the reference page on CREATE FOREIGN TABLE.
Good catch. Committed.
Thanks
On 2015/05/16 3:32, Robert Haas wrote:
On Thu, May 14, 2015 at 6:37 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
On second thought, I noticed that as for this option, we cannot live without
allowing IMPORT FOREIGN SCHEMA to return ALTER FOREIGN TABLE statements
because we cannot declare
On 2015/05/18 17:44, Amit Langote wrote:
On 2015-05-18 PM 05:03, Etsuro Fujita wrote:
On 2015/05/16 3:32, Robert Haas wrote:
On Thu, May 14, 2015 at 6:37 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
On second thought, I noticed that as for this option, we cannot live without
allowing
Hi,
Here is a patch to improve the ALTER FOREIGN TABLE documentation a bit:
(1) fix markup for ADD table_constraint [ NOT VALID ] and (2) remove an
unnecessary comma from an example query.
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/ref/alter_foreign_table.sgml b/doc/src/sgml/ref
Hi,
The attached patch adds missing NO INHERIT to the CHECK clause in the
synopsis section in the reference page on CREATE FOREIGN TABLE.
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/ref/create_foreign_table.sgml b/doc/src/sgml/ref/create_foreign_table.sgml
index abadd83..413b033 100644
. Am I right?
Comments welcome.
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
to heap_form_tuple,
but I dunno if we want to add even a small number of cycles for this
purpose to such a core function.
I thought so too when creating the first version.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/54b7691b.5080...@lab.ntt.co.jp
--
Sent via pgsql
On 2015/05/13 3:24, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
On 2015/05/12 7:42, Tom Lane wrote:
I don't much like the division of labor between LockForeignRow and
FetchForeignRow. In principle that would lead to not one but two
extra remote accesses per locked row
On 2015/05/13 0:55, Stephen Frost wrote:
Etsuro,
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
Here is an updated version. In this version, the bug has been
fixed, but any regression tests for that hasn't been added, because
I'm not sure that the above way is a good idea and don't have
On 2015/05/11 8:50, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ EvalPlanQual-v6.patch ]
I've started to study this in a little more detail, and I'm not terribly
happy with some of the API decisions in it.
Thanks for taking the time to review the patch
that is worth
much in practice.
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/04/30 17:15, Etsuro Fujita wrote:
On 2015/04/30 2:10, Robert Haas wrote:
On Mon, Apr 27, 2015 at 7:47 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Authorizing ALTER FOREIGN TABLE as query string that a FDW can use
with IMPORT FOREIGN SCHEMA is a different feature than what
On 2015/04/30 1:59, Robert Haas wrote:
On Mon, Apr 27, 2015 at 2:50 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Here is a patch to add missing tab-completion for ALTER FOREIGN TABLE.
I'll add this to the next CF.
Committed, thanks.
Thanks!
Best regards,
Etsuro Fujita
--
Sent via
On 2015/04/30 7:06, Robert Haas wrote:
On Thu, Apr 16, 2015 at 3:30 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Attached is a small patch to mark up on with literal in
doc/src/sgml/config.sgml.
Committed.
Thanks for picking this up!
Best regards,
Etsuro Fujita
--
Sent via pgsql
On 2015/04/29 4:35, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
On 2015/04/28 15:17, Amit Langote wrote:
The code at the beginning of ATSimpleRecursion() looks like -
if (recurse rel-rd_rel-relkind == RELKIND_RELATION)
Not sure if it's great idea, but now that foreign
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
. But I don't think the second case is a
bug. As described in the notes in the reference page on ALTER FOREIGN
TABLE, I think it should be the user's responsibility to ensure that the
foreign table definition matches the reality.
Best regards,
Etsuro Fujita
*** a/src/backend/commands/tablecmds.c
is a patch for that. I'll add this to the next CF.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/expected/postgres_fdw.out
--- b/contrib/postgres_fdw/expected/postgres_fdw.out
***
*** 3415,3420 CREATE TABLE import_source.t2 (c1 int default 42, c2 varchar NULL, c3 text colla
Here is a patch to add missing tab-completion for ALTER FOREIGN TABLE.
I'll add this to the next CF.
Best regards,
Etsuro Fujita
*** a/src/bin/psql/tab-complete.c
--- b/src/bin/psql/tab-complete.c
***
*** 1128,1134 psql_completion(const char *text, int start, int end
On 2015/04/27 15:51, Michael Paquier wrote:
On Mon, Apr 27, 2015 at 3:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
I noticed that there is no postgres_fdw option to control whether check
constraints on remote tables are included in the definitions of foreign
tables imported from
On 2015/04/23 0:34, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
postgres=# select * from ft1 for update;
ERROR: could not find junk tableoid1 column
I think this is a bug. Attached is a patch fixing this issue.
Pushed, thanks!
Thank you.
Best regards
On 2015/04/21 10:07, Kyotaro HORIGUCHI wrote:
At Mon, 20 Apr 2015 16:40:52 +0900, Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote
in 5534ad84.3020...@lab.ntt.co.jp
However, I'd
like to propose to rename Foreign Update (Foreign Delete) of
ModifyTable simply to Update (Delete) not only because
,
Etsuro Fujita
*** a/doc/src/sgml/fdwhandler.sgml
--- b/doc/src/sgml/fdwhandler.sgml
***
*** 242,254 IterateForeignScan (ForeignScanState *node);
para
Note that productnamePostgreSQL/productname's executor doesn't care
! whether the rows returned violate any
On 2015/04/17 13:16, Amit Langote wrote:
On 17-04-2015 PM 12:35, Etsuro Fujita wrote:
(2) that might cause the problem of associating subplans' update
information with subplans' scan information, pointed out by Tom [1].
Having realized how it really works now, my +1 to Foreign Modifying Scan
On 2015/04/16 16:05, Etsuro Fujita wrote:
On 2015/03/23 2:57, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ fdw-inh-8.patch ]
I've committed this with some substantial rearrangements, notably:
* As I mentioned earlier, I got rid of a few unnecessary restrictions
On 2015/03/23 2:57, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ fdw-inh-8.patch ]
I've committed this with some substantial rearrangements, notably:
* As I mentioned earlier, I got rid of a few unnecessary restrictions on
foreign tables so as to avoid introducing
the FDW to change the behavior of FOR NO
KEY UPDATE and/or FOR KEY SHARE row locking so as to match the local
semantics exactly.
BTW, I revised docs a bit. Attached is an updated version of the patch.
Best regards,
Etsuro Fujita
*** a/doc/src/sgml/fdwhandler.sgml
--- b/doc/src/sgml
Hi,
Attached is a small patch to mark up on with literal in
doc/src/sgml/config.sgml.
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index b30c68d..0d8624a 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -6752,7 +6752,7
On 2015/03/05 21:08, Etsuro Fujita wrote:
Here is an updated version.
The EXPLAIN output has also been improved as discussed in [1].
I noticed that the EXPLAIN for a pushed-down update (delete) on
inheritance childs doubly displays Foreign Update (Foreign Delete),
one for ForeignScan
On 2015/04/16 19:57, Amit Langote wrote:
On 16-04-2015 PM 07:50, Etsuro Fujita wrote:
The EXPLAIN output has also been improved as discussed in [1].
I noticed that the EXPLAIN for a pushed-down update (delete) on inheritance
childs doubly displays Foreign Update (Foreign Delete), one
On 2015/04/15 3:52, Alvaro Herrera wrote:
On 4/14/15 5:49 AM, Etsuro Fujita wrote:
postgres=# create foreign table ft1 (c1 int) server myserver options
(table_name 't1');
CREATE FOREIGN TABLE
postgres=# create foreign table ft2 (c1 int) server myserver options
(table_name 't2');
CREATE FOREIGN
On 2015/03/23 2:57, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ fdw-inh-8.patch ]
I've committed this with some substantial rearrangements, notably:
* I thought that if we were doing this at all, we should go all the way
and allow foreign tables to be both
On 2015/04/13 23:25, Jim Nasby wrote:
On 4/13/15 4:58 AM, Etsuro Fujita wrote:
On 2015/04/10 21:40, Etsuro Fujita wrote:
On 2015/04/09 12:07, Etsuro Fujita wrote:
I'll update the patch, which will contain only an infrastructure for
this in the PG core, and will not contain any postgres_fdw
On 2015/04/10 21:40, Etsuro Fujita wrote:
On 2015/04/09 12:07, Etsuro Fujita wrote:
I'll update the patch, which will contain only an infrastructure for
this in the PG core, and will not contain any postgres_fdw change.
I updated the patch based on your comments. Updated patch attached
On 2015/04/08 7:44, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
To support ROW_MARK_REFERENCE on (postgres_fdw) foreign tables, I'd like
to propose the following FDW APIs:
RowMarkType
GetForeignRowMarkType(Oid relid,
LockClauseStrength strength
On 2015/03/25 4:56, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Let me explain further. Here is the comment in ExecOpenScanRelation:
* Determine the lock type we need. First, scan to see if target
relation
* is a result relation. If not, check if it's
be appreciated if anyone could send back any comments earlier.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/option.c
--- b/contrib/postgres_fdw/option.c
***
*** 105,111 postgres_fdw_validator(PG_FUNCTION_ARGS)
* Validate option value, when we can do so without any context
On 2015/03/20 21:31, Bruce Momjian wrote:
On Thu, Oct 23, 2014 at 06:29:07PM +0900, Etsuro Fujita wrote:
I don't think that the lock level mentioned in the following comment in
MergeAttributes() in tablecmds.c is right, since that that function has
opened the relation
On 2015/03/21 5:58, Bruce Momjian wrote:
On Thu, Nov 13, 2014 at 08:30:49PM +0900, Etsuro Fujita wrote:
(2014/11/13 20:07), Heikki Linnakangas wrote:
On 11/13/2014 12:45 PM, Etsuro Fujita wrote:
It seems to me there are typos in the reference page for CREATE TABLE.
The structure
on this issue.
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
to handling a pushed-down update on a join.
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
, then it won't be terribly important
exactly what happens in that case, so we can just do some simple/easy
kluge in the short term and not have to have an argument about what's
the best thing to do.
That seems like a good idea.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql
501 - 600 of 949 matches
Mail list logo
