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
.)
tableoid | ctid | a
--+---+---
16459 | (0,0) | 1
(1 row)
Note the value of the ctid has changed!
Rather than changing nodeForeignscan.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
(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-hackers@postgresql.org)
To make changes to your subscription:
http
) | 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-happen
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 Fujita
[1] http://www.postgresql.org/message-id/23343.1418658
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 add
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 list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
On 2015/03/04 17:57, Shigeru Hanada wrote:
2015-03-04 17:00 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
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
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
tried to add
it.
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 pgsql
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 rowmark method
is being
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(), which
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 pgsql-hackers mailing
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
for postponing this whole patch until we
have join push-down.
I'll re-add this to the final CF. And 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:
http://www.postgresql.org/mailpref
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 relation
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 children. So the comment
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 regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql
On 2015/02/10 7:23, Dean Rasheed wrote:
On 9 February 2015 at 21:17, Stephen Frost sfr...@snowman.net 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
. 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-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
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_name 'lbt');
CREATE FOREIGN TABLE
Thanks for the review!
Best regards,
Etsuro Fujita
- 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)
Correct me if I am wrong.
Best regards,
Etsuro Fujita
--
Sent
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/mailpref
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 ever
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 here
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
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 problem
concerning the above idea?
Best regards,
Etsuro Fujita
--
Sent via pgsql
://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, values, nulls
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
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
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_fdw/input/file_fdw.source
--- b/contrib/file_fdw/input/file_fdw.source
***
*** 148,153
On 2014/12/18 7:04, Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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 patch
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.
Thanks,
Best regards,
Etsuro Fujita
(2014/12/18 17:34), Fujii Masao wrote:
On Thu, Dec 18, 2014 at 12:52 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
(2014/12/18 7:04), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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 modified
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/16 2:59), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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 missing something, but I think
(2014/12/12 11:33), Etsuro Fujita wrote:
(2014/12/12 11:19), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
(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
,
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/12 11:19), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
same type and found
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
fujita.ets...@lab.ntt.co.jp 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
() for XACT_EVENT_PRE_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/11/28 18:14), Ashutosh Bapat wrote:
On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
)
Output: (ft2.a * 2), ft2.ctid
Remote SQL: SELECT a, ctid FROM public.mytable_2 WHERE ((a =
5)) FOR UPDATE
(12 rows)
What do you say?
Sorry for the delay.
[1] http://www.postgresql.org/message-id/1316566782-sup-2...@alvh.no-ip.org
Best regards,
Etsuro Fujita
--
Sent via
(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 to your
(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 Fujita
--
Sent via
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 list (pgsql-hackers@postgresql.org)
To make
.
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_cxt-foreignrel-relid
(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
(2014/11/18 18:27), Ashutosh Bapat wrote:
On Tue, Nov 18, 2014 at 1:50 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
(2014/11/18 18:37), Ashutosh Bapat wrote:
On Tue, Nov 18, 2014 at 1:55 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
(2014/11/19 14:58), Ashutosh Bapat wrote:
On Wed, Nov 19, 2014 at 11:18 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
fujita.ets...@lab.ntt.co.jp
(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
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
(2014/11/17 19:54), Ashutosh Bapat wrote:
Here are comments for postgres_fdw
(2014/11/19 15:56), Ashutosh Bapat wrote:
On Wed, Nov 19, 2014 at 12:14 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
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
(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 any, you'll get a bunch
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-hackers mailing
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 (pgsql-hackers@postgresql.org
(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 utils
(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
(2014/11/06 23:38), Fujii Masao wrote:
On Tue, Nov 4, 2014 at 12:04 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
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 relhassubclass = true but no pg_inherits.inhparent
links
. 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 constraint_exclusion
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
fujita.ets...@lab.ntt.co.jp 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
(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
fujita.ets...@lab.ntt.co.jp wrote:
On Wed, Sep 10, 2014 at 10:37 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15
(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. Attached
(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/backend
(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
(2014/10/16 17:17), Simon Riggs wrote:
On 16 October 2014 06:49, Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
(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 defects go
(2014/10/16 11:45), Simon Riggs wrote:
On 6 October 2014 11:07, Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
(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/08 22:51), Fujii Masao wrote:
On Wed, Sep 24, 2014 at 11:10 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
On Wed, Sep 10, 2014 at 10:37 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
fujita.ets
-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_analyze_rel(Relation onerel, VacuumStmt *vacstmt
)),
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/13 2:42), Fujii Masao wrote:
On Wed, Sep 10, 2014 at 10:37 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
PENDING_LIST_CLEANUP_SIZE and work_mem, for this setting.
Wouldn't
(2014/09/17 1:58), Robert Haas wrote:
On Tue, Sep 16, 2014 at 11:31 AM, Kevin Grittner kgri...@ymail.com wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp 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
, the patch doesn't support OFFSET with UPDATE/DELETE ... LIMIT. Is
that OK? When we support ORDER BY ... LIMIT/OFFSET, we will also be
allowing for OFFSET with UPDATE/DELETE ... LIMIT. So, ISTM it would be
better for the patch to support OFFSET at this point. No?
Thanks,
Best regards,
Etsuro
Here is a patch to a bit improve the reference page for the LOCK
command. I think it'd be better for the isolation level to be in
capitals and wrapped in the literal tags.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml
index 26e424b
and bar are remote.
Maybe it's silly to worry about that until join push-down is done;
but in that case I'd vote for postponing this whole patch until we
have join push-down.
OK
Thanks,
PS: I'll help Hanada-san do the work if there is anything I can do.
Best regards,
Etsuro Fujita
--
Sent
(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.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
in mind. I'll work on that at the next CF.
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
match the remote side. Such constraints are
+ used for some kind of query optimization such as constraint exclusion
+ for partitioned tables
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
(2014/09/11 19:46), Heikki Linnakangas wrote:
On 09/11/2014 12:22 PM, Etsuro Fujita wrote:
(2014/09/11 4:32), Heikki Linnakangas wrote:
I had a cursory look at this patch and the discussions around this.
Thank you!
ISTM there are actually two new features in this: 1) allow CHECK
(2014/09/10 12:31), Fujii Masao wrote:
On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
(2014/09/09 22:17), Fujii Masao wrote:
Attached is the updated version of the patch.
I took a quick review on the patch. It looks good to me,
but one thing I'm
(2014/09/10 16:57), Marko Tiikkaja wrote:
On 2014-09-10 04:25, Etsuro Fujita wrote:
(2014/09/09 18:57), Heikki Linnakangas wrote:
What's not clear to me is whether it make sense to do 1) without 2) ? Is
UPDATE .. LIMIT without support for an ORDER BY useful enough? And if we
apply this patch
(2014/09/10 18:33), Marko Tiikkaja wrote:
On 9/10/14 11:25 AM, Etsuro Fujita wrote:
The reason is because I think that after implementing #2, we should
re-implement this feature by extending the planner to produce a plan
tree such as ModifyTable+Limit+Append, maybe with LockRows below the
Limit
on it (and postgres_fdw's update pushdown enhancement related to it)
at the next CF (I think I can do it earlier). I must apologize to Rukh
for not having enough time for the patch review.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
,
PENDING_LIST_CLEANUP_SIZE? How about setting PENDING_LIST_CLEANUP_SIZE
to work_mem as the default value when running the CREATE INDEX command?
Sorry for the delay.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
flag, as you proposed. Attached is the updated version of the
patch. In this version, I've also revised code and its comments a bit.
Sorry for the delay.
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgres_fdw/deparse.c
***
*** 188,197
(2014/09/02 18:55), Etsuro Fujita wrote:
(2014/09/01 20:15), Etsuro Fujita wrote:
While working on [1], I've found that postgres_fdw behaves oddly:
I've revised the patch a bit further. Please find attached a patch.
Thanks,
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
(2014/09/01 20:15), Etsuro Fujita wrote:
While working on [1], I've found that postgres_fdw behaves oddly:
postgres=# create foreign table ft (a int) server loopback options
(table_name 't');
CREATE FOREIGN TABLE
postgres=# select tableoid, * from ft;
tableoid
?id=1386
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgres_fdw/deparse.c
***
*** 243,248 foreign_expr_walker(Node *node,
--- 243,254
Var *var = (Var *) node;
/*
+ * System columns can't be sent to remote
601 - 700 of 949 matches
Mail list logo
