On 2015/04/08 7:44, Tom Lane wrote:
> Etsuro Fujita writes:
>> To support ROW_MARK_REFERENCE on (postgres_fdw) foreign tables, I'd like
>> to propose the following FDW APIs:
>
>> RowMarkType
>> GetForeignRowMarkType(Oid relid,
>> L
.
It'd 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 with
On 2015/03/25 4:56, Tom Lane wrote:
> Etsuro Fujita 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,
o do there.
Will work 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
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 of the
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
at happens
> with those whole-tree stats when some of the children are foreign tables
> that lack ANALYZE support. If the long-term plan is that whole-tree
> stats are going away altogether, then it won't be terribly important
> exactly what happens in that case, so we can just d
rrent CF, to scale
up 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
On 2015/03/13 11:46, Etsuro Fujita wrote:
BTW, what do you think about opening/locking foreign tables selected for
update at InitPlan, which the original patch does? As I mentioned in
[1], ISTM that ExecOpenScanRelation called from ExecInitForeignScan is
assuming that.
[1] http
patch does? As I mentioned in
[1], ISTM that ExecOpenScanRelation called from ExecInitForeignScan is
assuming that.
Best regards,
Etsuro Fujita
[1] http://www.postgresql.org/message-id/54bcbbf8.3020...@lab.ntt.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
scan.c, it might be better to change
heap_form_tuple to set the t_ctid of a formed tuple to be invalid.
Thanks for the review!
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
(if
necessary), and then the t_self will be correctly assigned (0,0) throguh
the whole-row Var in EvalPlanQualFetchRowMarks. So, no inconsistency!
Apart from this, I do not have any comments here.
Thanks again.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-ha
+---
0 | (4294967295,0) | 1
(1 row)
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/03/04 17:07, Etsuro Fujita wrote:
On 2015/03/04 16:58, Albe Laurenz wrote:
Etsuro Fujita wrote:
While updating the patch, I noticed that in the previous patch, there is
a bug in pushing down parameterized UPDATE/DELETE queries; generic plans
for such queries fail with a can't-h
On 2015/03/04 17:57, Shigeru Hanada wrote:
2015-03-04 17:00 GMT+09:00 Etsuro Fujita :
On 2015/03/03 21:34, Shigeru Hanada wrote:
I rebased "join push-down" patch onto Kaigai-san's Custom/Foreign Join
v6 patch.
but still the patch
has an issue about joins underlying UPDATE
[2], and I'd like to work on that
together!
Hanada-san, could you give us test query to reproduce the problem
above? I and Fujita-san can help to investigate the problem from
different standpoints for each.
Yeah, will do.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing li
On 2015/03/04 16:58, Albe Laurenz wrote:
Etsuro Fujita wrote:
While updating the patch, I noticed that in the previous patch, there is
a bug in pushing down parameterized UPDATE/DELETE queries; generic plans
for such queries fail with a can't-happen error. I fixed the bug and
tried to ad
something like "UPDATE foo ... FROM bar ..." where both foo and
bar are remote? If so, I think it'd be better to push such an update
down to the remote, as discussed in [2], and I'd like to work on that
together!
Sorry for having been late for the party.
Best regards,
Etsuro Fu
On 2015/02/16 12:03, Etsuro Fujita wrote:
> I'll update the patch.
While updating the patch, I noticed that in the previous patch, there is
a bug in pushing down parameterized UPDATE/DELETE queries; generic plans
for such queries fail with a can't-happen error. I fixed the bug and
.
I've pushed a fix for this.
Thanks!
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/02/26 11:38, Stephen Frost wrote:
I've pushed an update for this to master and 9.4 and improved the
comments and the commit message as discussed.
Would be great if you could test and let me know if you run into any
issues!
OK, thanks!
Best regards,
Etsuro Fujita
--
Sent via
On 2015/01/15 16:35, Etsuro Fujita wrote:
> On 2014/12/23 0:36, Tom Lane wrote:
>> Yeah, we need to do something about the PlanRowMark data structure.
>> Aside from the pre-existing issue in postgres_fdw, we need to fix it
>> to support inheritance trees in which more than one
On 2015/02/18 21:44, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
On 2015/02/18 7:44, Stephen Frost wrote:
Attached is a patch which should address this. Would love your (or
anyone else's) feedback on it. It appears to address the issue which
you raised an
On 2015/02/18 8:13, Tom Lane wrote:
> So I went back to your v1 patch and have now committed that with some
> cosmetic modifications. Sorry for making you put time into a dead end.
I don't mind it. Thanks for committing the patch!
Best regards,
Etsuro Fujita
--
Sent via pg
On 2015/02/18 7:44, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
On 2015/02/11 4:06, Stephen Frost wrote:
I had been trying to work out an FDW-specific way to address this, but I
think Dean's right that this should be addressed in
expand_security_qual(),
> The only thing that's bothering me about this concept is that I'm not
> seeing how to scale it up to handling a pushed-down update on a join,
> ie, "UPDATE foo ... FROM bar ..." where both foo and bar are remote.
> Maybe it's silly to worry about that until join p
On 2015/02/11 4:06, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
On 2015/02/10 7:23, Dean Rasheed wrote:
Sorry, I didn't have time to look at this properly. My initial thought
is that expand_security_qual() needs to request a lock on rows coming
>from the
On 2015/02/10 14:49, Etsuro Fujita wrote:
> On 2015/02/07 1:09, Tom Lane wrote:
>> IIRC, this code was written at a time when we didn't have NO INHERIT check
>> constraints and so it was impossible for the parent table to get optimized
>> away while leaving ch
On 2015/02/10 7:23, Dean Rasheed wrote:
On 9 February 2015 at 21:17, Stephen Frost wrote:
On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
I noticed that when updating security barrier views on foreign tables,
we fail to give FOR UPDATE to selection queries issued at ForeignScan.
I've l
e parent RTI. Then you would probably end up with a net
> savings of code rather than net addition; certainly ExplainModifyTarget
> would go away entirely since you'd just treat ModifyTable like any other
> Scan in this part of EXPLAIN.
Will follow your revision.
Thanks!
Best reg
;
CREATE TABLE
postgres=# create server loopback foreign data wrapper postgres_fdw
options (dbname 'efujita');
CREATE SERVER
postgres=# create user mapping for current_user server loopback;
CREATE USER MAPPING
postgres=# create foreign table ft (a int) server loopback options
(table_
ified e.g
Update on child1, child2, child3. That will disambiguate everything.
That's an idea, but my concern about that is the cases where there are a
large number of child tables as the EXPLAIN would be difficult to read
in such cases.
Best regards,
Etsuro Fujita
--
Sent via pgsql-h
h=6)
Output: base_ftbl.ctid
-> Foreign Scan on public.base_ftbl base_ftbl_2
(cost=100.00..144.40 rows=14 width=6)
Output: base_ftbl_2.ctid
Remote SQL: SELECT ctid FROM public.base_tbl WHERE
((visibility = 'public'::text))
(7 rows)
Corre
On 2015/01/19 17:10, Etsuro Fujita wrote:
Attached is an updated version of the patch.
I'll add this to the next CF.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
On 2015/01/27 9:15, Jim Nasby wrote:
On 12/22/14 12:50 AM, Etsuro Fujita wrote:
I think ExplainModifyTarget should show the parent of the inheritance
tree in multi-target-table cases, as described there, but noticed that
it doesn't always work like that. Here is an example.
Anything
On 2015/01/20 1:44, Robert Haas wrote:
On Mon, Jan 19, 2015 at 4:00 AM, Etsuro Fujita
wrote:
I ran into another typo in execMain.c. Patch attached.
Thanks, committed!
Thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi,
I ran into another typo in execMain.c. Patch attached.
Best regards,
Etsuro Fujita
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index fcc42fa..bc910f0 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -2182,7 +2182,7
On 2015/01/16 1:24, Alvaro Herrera wrote:
Etsuro Fujita wrote:
*** 817,826 InitPlan(QueryDesc *queryDesc, int eflags)
--- 818,833
break;
case ROW_MARK_COPY:
/* there's no real table
ugh, and probably won't get to it until
> after Christmas. One thing that's not clear is what should happen
> with ExecRowMark.
As I said before, that seems to me like a good idea. So I'll update the
patch based on that if you're okey with it. Or you've found any prob
of this.
[1] https://commitfest.postgresql.org/action/patch_view?id=1386
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/postgres_fdw.c
--- b/contrib/postgres_fdw/postgres_fdw.c
***
*** 2947,2953 make_tuple_from_result_row(PGresult *res,
tuple = heap_form_tuple(tupdesc, valu
On 2015/01/10 1:08, Stephen Frost wrote:
* Etsuro Fujita (fujita.ets...@lab.ntt.co.jp) wrote:
I ran into a comment type. Please find attached a patch.
Fix pushed.
Thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
Hi,
I ran into a comment type. Please find attached a patch.
Best regards,
Etsuro Fujita
diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 8c799d3..28abfa4 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -2024,7 +2024,7
rees
during the EPQ processing.:-( Attached is an updated version of the
patch to fix that, which has been created on top of [1], as said before.
Thanks,
[1] http://www.postgresql.org/message-id/5497bf4c.6080...@lab.ntt.co.jp
Best regards,
Etsuro Fujita
*** a/contrib/file_f
On 2014/12/18 7:04, Tom Lane wrote:
> Etsuro Fujita writes:
>> Attached are updated patches. Patch fdw-inh-5.patch has been created on
>> top of patch fdw-chk-5.patch.
> I've committed fdw-chk-5.patch with some minor further adjustments;
> Have not looked at the other
a field to ModifyTable to record the parent, apart from
resultRelations. (More precisely, the parent in its role as a simple
member of the inheritance tree is recorded so that appending digits to
refname in select_rtable_names_for_explain works as before.) Attached
is a proposed patch for that.
Than
(2014/12/18 17:34), Fujii Masao wrote:
On Thu, Dec 18, 2014 at 12:52 PM, Etsuro Fujita
wrote:
The attached patch just removes one bad-looking blank line in the
comments at the top of a function in explain.c.
Applied.
Thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing
Hi,
The attached patch just removes one bad-looking blank line in the
comments at the top of a function in explain.c.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/backend/commands/explain.c b/src/backend/commands/explain.c
index 332f04a..064f880 100644
--- a/src/backend/commands
(2014/12/18 7:04), Tom Lane wrote:
> Etsuro Fujita writes:
>> Attached are updated patches. Patch fdw-inh-5.patch has been created on
>> top of patch fdw-chk-5.patch. Patch fdw-chk-5.patch is basically the
>> same as the previous one fdw-chk-4.patch, but I slightly modif
(2014/12/16 2:59), Tom Lane wrote:
> Etsuro Fujita writes:
>> (2014/12/13 1:17), Tom Lane wrote:
>>> We should
>>> probably also think about allowing FDWs to change these settings if
>>> they want to.
>
>> This is not clear to me. Maybe I'm m
(2014/12/13 1:17), Tom Lane wrote:
> Etsuro Fujita writes:
>>> (2014/12/12 10:37), Tom Lane wrote:
>>>> Yeah, this is clearly a thinko: really, nothing in the planner should
>>>> be using get_parse_rowmark(). I looked around for other errors
(2014/12/12 11:33), Etsuro Fujita wrote:
> (2014/12/12 11:19), Tom Lane wrote:
>> Etsuro Fujita writes:
>>> (2014/12/12 10:37), Tom Lane wrote:
>>>> Yeah, this is clearly a thinko: really, nothing in the planner should
>>>> be using get_parse_rowmark()
(2014/12/12 11:19), Tom Lane wrote:
> Etsuro Fujita writes:
>> (2014/12/12 10:37), Tom Lane wrote:
>>> Yeah, this is clearly a thinko: really, nothing in the planner should
>>> be using get_parse_rowmark(). I looked around for other errors of the
&
means for a remote table that we
don't have
[1] http://www.postgresql.org/message-id/5487bb9d.7070...@lab.ntt.co.jp
Thanks,
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
(2014/12/11 14:54), Ashutosh Bapat wrote:
I marked this as ready for committer.
Many thanks!
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's ask for the
committer's review!
Thanks,
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
Hi Ashutosh,
Thanks for the review!
(2014/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/17 17:55), Ashutosh Bapat wrote:
Here are my review comments for patch fdw-inh-3.patch.
COMMIT for foo succeeded and
then that for bar failed during CommitTransaction().
Thanks,
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
(2014/12/07 2:02), David Fetter wrote:
On Thu, Dec 04, 2014 at 12:35:54PM +0900, Etsuro Fujita wrote:
But I think
there would be another idea. An example will be shown below. We show the
update commands below the ModifyTable node, not above the corresponding
ForeignScan nodes, so maybe less
(2014/12/03 19:35), Ashutosh Bapat wrote:
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
This is not exactly extension of non-inheritance case. non-inheritance
case doesn't show two remote SQLs under the same plan node. May be you
can
(2014/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
Apart from the above, I noticed that the patch doesn't consider to
call ExplainForeignModify during EXPLAIN for an inherited
UPDATE/DELET
ign Scan on public.ft1 (cost=100.00..140.38 rows=12 width=10)
Output: (ft1.a * 2), ft1.ctid
Remote SQL: SELECT a, ctid FROM public.mytable_1 WHERE ((a =
5)) FOR UPDATE
Remote SQL: UPDATE public.mytable_2 SET a = $2 WHERE ctid = $1
-> Foreign Scan on public.ft2 (c
(2014/11/23 6:16), Tom Lane wrote:
> I committed this with some cosmetic adjustments, and one not-so-cosmetic
> one:
Thanks for improving and committing the patch!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
(2014/11/19 18:21), Ashutosh Bapat wrote:
Ok. I added that comment to the commitfest and changed the status to
"ready for commiter".
Many thanks!
PS: the link to the review emails that discuss the issue doesn't work
properly, so I re-added the link.
Best regards,
Etsuro F
(2014/11/19 15:56), Ashutosh Bapat wrote:
On Wed, Nov 19, 2014 at 12:14 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/19 14:58), Ashutosh Bapat wrote:
May be we should modify use_physical_tlist() to return
false in
c
(2014/11/19 14:55), Etsuro Fujita wrote:
(2014/11/18 18:37), Ashutosh Bapat wrote:
On Tue, Nov 18, 2014 at 1:55 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/17 19:54), Ashutosh Bapat wrote:
Here are comments for postgres_fdw-syscol patch.
(2014/11/19 14:58), Ashutosh Bapat wrote:
On Wed, Nov 19, 2014 at 11:18 AM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/18 18:27), Ashutosh Bapat wrote:
On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita
Here are my comments abo
(2014/11/18 18:37), Ashutosh Bapat wrote:
On Tue, Nov 18, 2014 at 1:55 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/17 19:54), Ashutosh Bapat wrote:
Here are comments for postgres_fdw-syscol patch.
Code
---
1. Instea
(2014/11/18 18:27), Ashutosh Bapat wrote:
On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
(2014/11/17 19:36), Ashutosh Bapat wrote:
Here are my comments about the patch fscan_reltargetlist.patch
2. Instead of usi
(2014/11/18 18:09), Ashutosh Bapat wrote:
I looked at the patch. It looks good now. Once we have the inh patch
ready, we can mark this item as ready for commiter.
Thanks for the review!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
postgres_fdw.
Done.
Please find attached an updated version of the patch.
Thanks,
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgres_fdw/deparse.c
***
*** 253,258 foreign_expr_walker(Node *node,
--- 253,268
if (var->varno == glob
ist
rather than rel->reltargetlist.
* I think that it'd improve the readability to match the code with other
places that execute similar processing, such as check_index_only() and
remove_unused_subquery_outputs().
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing
wConstraints,
to match the other message there.
* Revised other docs a little bit.
Attached is an updated version of the patch.
Thanks,
Best regards,
Etsuro Fujita
*** a/contrib/file_fdw/input/file_fdw.source
--- b/contrib/file_fdw/input/file_fdw.source
***
*** 62,68 CREATE FORE
(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 of the sentence is a bit funky, but it seems correct to
> me. If you google for "should a
It seems to me there are typos in the reference page for CREATE TABLE.
Please find attached a patch.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml
index 299cce8..ebcb885 100644
--- a/doc/src/sgml/ref/create_table.sgml
source and
doc/src/sgml/ref/create_foreign_table.sgml
As I said upthread, fdw-inh-3.patch has been created on top of [1] and
fdw-chk-3.patch. Did you apply these patche first?
[1] https://commitfest.postgresql.org/action/patch_view?id=1599
Best regards,
Etsuro Fujita
--
Sent via pgsql-hacke
(2014/11/11 18:45), Etsuro Fujita wrote:
(2014/11/10 20:05), Ashutosh Bapat wrote:
Since two separate issues 1. using reltargetlist instead of attr_needed
and 2. system columns usage in FDW are being tackled here, we should
separate the patch into two one for each of the issues.
Agreed. Will
(2014/11/11 2:31), Fujii Masao wrote:
On Mon, Nov 10, 2014 at 4:15 PM, Etsuro Fujita
The patch looks good to me except for the following point:
*** a/src/backend/access/gin/ginfast.c
--- b/src/backend/access/gin/ginfast.c
***
*** 25,30
--- 25,32
#include "
mismatching between such an enforcement and
postgres_fdw, which sends the ctid column to the remote side internally
when executing UPDATE/DELETE on foreign tables. See
postgresPlanForeignModify and eg, deparseUpdateSql.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgs
(2014/11/06 23:38), Fujii Masao wrote:
On Tue, Nov 4, 2014 at 12:04 PM, Etsuro Fujita
wrote:
IIUC, I think that min = 0 disables fast update, so ISTM that it'd be
appropriate to set min to some positive value. And ISTM that the idea of
using the min value of work_mem is not so bad.
us
patch. The updated patch fixes that, adds a bit more docs, and revises
regression tests in foreign_data.sql a bit further.
Thanks,
Best regards,
Etsuro Fujita
*** a/contrib/file_fdw/input/file_fdw.source
--- b/contrib/file_fdw/input/file_fdw.source
***
*** 144,149 SET const
Hi Furuya-san,
(2014/11/07 16:54), furu...@pm.nttdata.co.jp wrote:
>> (2014/08/28 18:00), Etsuro Fujita wrote:
>>> (2014/08/22 11:51), Noah Misch wrote:
>>>> Today's ANALYZE VERBOSE messaging for former inheritance parents
>>>> (tables with relhas
(2014/11/06 20:04), Fujii Masao wrote:
On Thu, Nov 6, 2014 at 7:44 PM, Etsuro Fujita
wrote:
I ran into a typo in a comment in src/backend/commands/matview.c.
Please find attached a patch.
Thanks! Applied.
Thanks!
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql
I ran into a typo in a comment in src/backend/commands/matview.c.
Please find attached a patch.
Best regards,
Etsuro Fujita
diff --git a/src/backend/commands/matview.c b/src/backend/commands/matview.c
index 30bd40d..db05f7c 100644
--- a/src/backend/commands/matview.c
+++ b/src/backend/commands
(2014/10/30 21:30), Fujii Masao wrote:
On Thu, Oct 30, 2014 at 7:30 PM, Etsuro Fujita
wrote:
Here are my review comments.
* The patch applies cleanly and make and make check run successfully. I
think that the patch is mostly good.
Thanks! Attached is the updated version of the patch
(2014/10/09 11:49), Etsuro Fujita wrote:
(2014/10/08 22:51), Fujii Masao wrote:
On Wed, Sep 24, 2014 at 11:10 AM, Etsuro Fujita
wrote:
On Wed, Sep 10, 2014 at 10:37 PM, Alvaro Herrera
wrote:
Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
wrote
(2014/10/17 18:35), Etsuro Fujita wrote:
(2014/10/16 17:17), Simon Riggs wrote:
Would it be useful to keep track of how many tables just got analyzed?
i.e. analyze of foo (including N inheritance children)
I think that's a good idea. So, I'll update the patch.
Done. Atta
(2014/10/21 17:40), Etsuro Fujita wrote:
(2014/10/14 20:00), Etsuro Fujita wrote:
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
fdw-inh.patch - table inheritance with foreign tables
The latter has been created on top of [1].
[1] http://www.postgresql.org
, but keep our AccessShareLock on it
until xact
1751 * commit. That will prevent someone else from deleting or
ALTERing
1752 * the parent before the child is committed.
1753 */
1754 heap_close(relation, NoLock);
Thanks,
Best regards,
Etsuro Fujita
*** a/src/ba
(2014/10/14 20:00), Etsuro Fujita wrote:
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
fdw-inh.patch - table inheritance with foreign tables
The latter has been created on top of [1].
[1] http://www.postgresql.org/message-id/540da168.3040...@lab.ntt.co.jp
I ran into a type " a a " in a comment in snapmgr.c, and found that
there are four other places that've made the same typo, by the grep
command. And in one of those places, I found yet another typo. Please
find attached a patch.
Thanks,
Best regards,
Etsuro Fujita
diff --gi
(2014/10/16 17:17), Simon Riggs wrote:
On 16 October 2014 06:49, Etsuro Fujita wrote:
How about this?
automatic analyze of table \"%s.%s.%s\" as inheritance tree
Thank you for the comment.
Would it be useful to keep track of how many tables just got analyzed?
i.e. anal
(2014/08/28 18:00), Etsuro Fujita wrote:
(2014/08/22 11:51), Noah Misch wrote:
Today's ANALYZE VERBOSE messaging for former inheritance parents
(tables with
relhassubclass = true but no pg_inherits.inhparent links) is
deceptive, and I
welcome a fix to omit the spurious message. As defec
(2014/10/16 11:45), Simon Riggs wrote:
On 6 October 2014 11:07, Etsuro Fujita wrote:
I noticed that analyze messages shown by autovacuum don't discriminate
between non-inherited cases and inherited cases, as shown in the below
example:
LOG: automatic analyze of table "postgres
(2014/09/12 16:30), Etsuro Fujita wrote:
(2014/09/11 20:51), Heikki Linnakangas wrote:
On 09/11/2014 02:30 PM, Etsuro Fujita wrote:
So, should I split the patch into the two?
Yeah, please do.
OK, Will do.
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
(2014/10/14 8:53), Robert Haas wrote:
On Mon, Oct 13, 2014 at 3:30 PM, Bruce Momjian wrote:
Uh, where are we on this patch?
Probably it should be added to the upcoming CF.
Done.
https://commitfest.postgresql.org/action/patch_view?id=1599
Thanks,
Best regards,
Etsuro Fujita
--
Sent via
(2014/10/08 22:51), Fujii Masao wrote:
On Wed, Sep 24, 2014 at 11:10 AM, Etsuro Fujita
wrote:
On Wed, Sep 10, 2014 at 10:37 PM, Alvaro Herrera
wrote:
Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
wrote:
PENDING_LIST_CLEANUP_SIZE and work_mem, for this setting
d cases, in
order to easily distinguish such cases from non-inherited cases. Please
find attached a patch. I'll add this to the upcoming CF.
Thanks,
Best regards,
Etsuro Fujita
*** a/src/backend/commands/analyze.c
--- b/src/backend/commands/analyze.c
***
*** 648,659 do_a
)),
fld2, FieldStore(placeholder, subfld2, y))
Patch attached.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/backend/rewrite/rewriteHandler.c b/src/backend/rewrite/rewriteHandler.c
index cb65c05..93fda07 100644
--- a/src/backend/rewrite/rewriteHandler.c
+++ b/src/backend/rewrite
(2014/09/17 1:58), Robert Haas wrote:
On Tue, Sep 16, 2014 at 11:31 AM, Kevin Grittner wrote:
Etsuro Fujita wrote:
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own feature. This version plays nicely
(2014/09/13 2:42), Fujii Masao wrote:
On Wed, Sep 10, 2014 at 10:37 PM, Alvaro Herrera
wrote:
Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
wrote:
PENDING_LIST_CLEANUP_SIZE and work_mem, for this setting.
Wouldn't it be easy-to-use to have only one para
601 - 700 of 967 matches
Mail list logo
