(2014/08/25 15:48), 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 with
inheritance. The intended use is splitting up big UPDATEs and DELETEs
into batches
(2014/08/22 11:51), Noah Misch wrote:
On Wed, Aug 20, 2014 at 08:11:01PM +0900, Etsuro Fujita wrote:
(2014/07/02 11:23), Noah Misch wrote:
Your chosen ANALYZE behavior is fair, but the messaging from a database-wide
ANALYZE VERBOSE needs work:
INFO: analyzing test_foreign_inherit.parent
INFO
does not matter, but is there a reason to do it different from the
normal scan?
Hmm, I'm worried that may be an API contract violation.
Will fix.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
...
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/08/13 12:40), Etsuro Fujita wrote:
(2014/08/12 18:34), Shigeru Hanada wrote:
Issues addressed by Eitoku-san were fixed properly, but he found a bug
and a possible enhancement in the v2 patch.
* push-down check misses delete triggers
update_is_pushdown_safe() seems to have a bug
(2014/08/26 12:20), Etsuro Fujita wrote:
(2014/08/25 21:58), Albe Laurenz wrote:
I played with it, and apart from Hanada's comments I have found the
following:
test= EXPLAIN (ANALYZE, VERBOSE) UPDATE rtest SET val=NULL WHERE id 3
(2014/08/27 3:27), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ attr_needed-v4.patch ]
I looked this over, and TBH I'm rather disappointed. The patch adds
150 lines of dubiously-correct code in order to save ... uh, well,
Just for my study, could you tell me why you
(2014/08/27 11:06), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
(2014/08/27 3:27), Tom Lane wrote:
I looked this over, and TBH I'm rather disappointed. The patch adds
150 lines of dubiously-correct code in order to save ... uh, well,
Just for my study, could you tell
.
Before looking into the patch, I'd like to know the use cases in more
details.
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
, that is right. As ModifyTable doesn't support rescan currently,
postgresReScanForeignScan needn't to be called in the update pushdown
case. The assertion is a good idea. I'll add it.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
.
I'll sympathize with that complaint.
Agreed on that.
I've got the point. Will fix.
Thanks for the comment!
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/08/21 13:21), Ashutosh Bapat wrote:
On Wed, Aug 20, 2014 at 3:25 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
Hi Ashutish,
I am sorry that I mistook your name's spelling.
(2014/08/14 22:30), Ashutosh Bapat wrote:
On Thu
.
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 Ashutish,
(2014/08/14 22:30), Ashutosh Bapat wrote:
On Thu, Aug 14, 2014 at 10:05 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
(2014/08/08 18:51), Etsuro Fujita wrote:
(2014/06/30 22:48), Tom Lane wrote:
I wonder whether it isn't
not
requests for you to change the patch, but they may deserve more discussion.
I'd like to give my opinions on those things later on.
Sorry for the long delay.
[1] http://www.postgresql.org/message-id/53f4707c.8030...@lab.ntt.co.jp
Best regards,
Etsuro Fujita
*** a/contrib/file_fdw/file_fdw.c
the state of the following patch from Returned with Feedback
to Needs Review.
https://commitfest.postgresql.org/action/patch_view?id=1386
Patch authors
-
Also, please pick a patch or two, submitted by other people, and review
them.
Will do.
Thanks,
Best regards,
Etsuro Fujita
(2014/08/08 18:51), Etsuro Fujita wrote:
(2014/06/30 22:48), Tom Lane wrote:
I wonder whether it isn't time to change that. It was coded like that
originally only because calculating the values would've been a waste of
cycles at the time. But this is at least the third place where it'd
for the users to
understand which expression is safe to send. So I agree with that
enhancement, but ISTM that it would be better to do that as a separate
patch.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
(2014/08/06 20:43), Etsuro Fujita wrote:
(2014/06/30 22:48), Tom Lane wrote:
I wonder whether it isn't time to change that. It was coded like that
originally only because calculating the values would've been a waste of
cycles at the time. But this is at least the third place where it'd
(2014/07/01 11:10), Etsuro Fujita wrote:
(2014/06/30 22:48), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Done. I think this is because create_foreignscan_plan() makes reference
to attr_needed, which isn't computed for inheritance children.
I wonder whether it isn't
(2014/07/30 17:22), Etsuro Fujita wrote:
(2014/07/29 0:58), Robert Haas wrote:
On Fri, Jul 25, 2014 at 3:39 AM, Albe Laurenz
laurenz.a...@wien.gv.at wrote:
Shigeru Hanada wrote:
* Naming of new behavior
You named this optimization Direct Update, but I'm not sure that
this is intuitive enough
Hi Hanada-san,
Thank you for the answer.
(2014/08/04 19:36), Shigeru Hanada wrote:
2014-07-25 16:30 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/07/24 18:30), Shigeru Hanada wrote:
I'm not sure that I understand your question correctly, but the reason for
that is because foreign
, I don't have
a strong opinion on whether that's better than direct update in this
context.
Update Pushdown is fine with me.
If there are no objections of others, I'll change the name from Direct
Update to Update Pushdown.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing
(2014/07/24 18:30), Shigeru Hanada wrote:
My coworker Takaaki EITOKU reviewed the patch, and here are some
comments from him.
Thank you for the review, Eitoku-san!
2014-07-08 16:07 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
In the patch postgresPlanForeignModify has been modified
/subquerypath.c.
+1
Sorry for the late reply.
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/07/14 19:46), Fujii Masao wrote:
On Mon, Jul 14, 2014 at 7:31 PM, Shigeru Hanada
shigeru.han...@gmail.com wrote:
Fujita-san,
2014-07-11 18:22 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
I think the following comment for store_returning_result() in
postgres_fdw.c is not right
(2014/07/14 21:01), Fujii Masao wrote:
On Fri, Jul 11, 2014 at 7:21 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Jul 11, 2014 at 5:45 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
I've noticed that EXPLAIN ANALYZE shows no information on exact/lossy
blocks for a bitmap heap scan
(2014/07/10 18:12), Shigeru Hanada wrote:
2014-06-24 16:30 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/06/23 18:35), Ashutosh Bapat wrote:
Selecting tableoid on parent causes an error, ERROR: cannot extract
system attribute from virtual tuple. The foreign table has an OID
(2014/07/11 15:50), Etsuro Fujita wrote:
(2014/07/10 18:12), Shigeru Hanada wrote:
IIUC, you mean that tableoid can't be retrieved when a foreign table
is accessed via parent table,
No. What I want to say is that tableoid *can* be retrieved when a
foreign table is accessed via the parent
time=0.003..0.003 rows=0 loops=1)
Index Cond: (test.id 10)
Buffers: shared hit=2
Planning time: 0.118 ms
Execution time: 0.027 ms
(10 rows)
Thanks,
Best regards,
Etsuro Fujita
*** a/src/backend/commands/explain.c
--- b/src/backend/commands/explain.c
and pasted from that for
get_remote_estimate().)
Thanks,
Best regards,
Etsuro Fujita
diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c
index 7dd43a9..f328833 100644
--- a/contrib/postgres_fdw/postgres_fdw.c
+++ b/contrib/postgres_fdw/postgres_fdw.c
@@ -2257,7
))
Planning time: 0.101 ms
Execution time: 8.808 ms
(6 rows)
I'll add this to the next CF. Comments are welcome.
Thanks,
Best regards,
Etsuro Fujita
*** a/contrib/postgres_fdw/deparse.c
--- b/contrib/postgres_fdw/deparse.c
***
*** 189,198 is_foreign_expr(PlannerInfo *root
to move this to the next CF.
http://www.postgresql.org/message-id/3492.1404136...@sss.pgh.pa.us
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/07/02 18:19), Abhijit Menon-Sen wrote:
Thanks for the update. I have marked the patch returned with feedback
and moved it to the 2014-08 CF.
OK I've changed the status from returned with feedback to Waiting on
Author.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers
(2014/07/01 15:13), Ashutosh Bapat wrote:
On Tue, Jul 1, 2014 at 7:39 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
We may want to modify use_physical_tlist(), to return false, in case of
foreign tables. BTW, it does return false for inheritance trees
(2014/07/01 16:04), Ashutosh Bapat wrote:
On Tue, Jul 1, 2014 at 12:25 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
Maybe I'm missing something, but what's the point of using the
tlist, not reltargetlist?
Compliance with other create_
Fujita
On Mon, Jun 30, 2014 at 12:22 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
(2014/06/24 16:30), Etsuro Fujita wrote:
(2014/06/23 18:35), Ashutosh Bapat wrote:
Selecting tableoid on parent causes an error, ERROR
(2014/06/30 20:17), Ashutosh Bapat wrote:
On Mon, Jun 30, 2014 at 4:17 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp mailto:fujita.ets...@lab.ntt.co.jp wrote:
(2014/06/30 17:47), Ashutosh Bapat wrote:
BTW, why aren't you using the tlist passed to this function? I guess
(2014/06/30 22:48), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Done. I think this is because create_foreignscan_plan() makes reference
to attr_needed, which isn't computed for inheritance children.
I wonder whether it isn't time to change that. It was coded like
table.
Do we want to do that?
No. I think it's a bug. I'll fix it.
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
be very useful. So, I plan to add a patch for it to
2014-08.
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
you for the review.
I added this to 2014-06 and marked it as Ready for Committer.
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/04/02 21:25), Etsuro Fujita wrote:
Attached is v11.
Changes:
* Rebased to head
* Improve an error message added to tablecmd.c to match it to existing
ones there
* Improve the documentaion a bit
I moved this to 2014-06.
Since I've merged with the initial patch by Hanada-san (1
(2014/05/05 23:05), Robert Haas wrote:
On Wed, Apr 30, 2014 at 4:10 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
(2014/04/28 23:31), Robert Haas wrote:
On Thu, Apr 24, 2014 at 7:59 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
The patch attached improves docs
(2014/04/28 23:31), Robert Haas wrote:
On Thu, Apr 24, 2014 at 7:59 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
The patch attached improves docs in fdwhandler.sgml a little bit.
When you submit a patch, it's helpful to describe what the patch
actually does, rather than just saying
Hi all,
The patch attached improves docs in fdwhandler.sgml a little bit.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler.sgml
index 9c818cd..ffb38af 100644
--- a/doc/src/sgml/fdwhandler.sgml
+++ b/doc/src/sgml/fdwhandler.sgml
@@ -873,11
(2014/04/15 15:27), Etsuro Fujita wrote:
(2014/04/14 23:53), Robert Haas wrote:
On Fri, Apr 11, 2014 at 5:00 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Attached is an updated version of the patch.
I think the other changes deserve to be considered separately, and in
particular I'm
of validating generic column/table
options, I think we would probably need to restrict LIKE to copy from
another foreign table maybe using the same FDW. So, I'd like to vote
for Tom's idea.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
(2014/04/04 13:35), Etsuro Fujita wrote:
If I understand correctly, foreign tables cannot have an OID column, but
the following code in DefineRelation() assumes that foreign tables *can*
have that coulum:
On second thought I noticed that that makes CREATE FOREIGN TABLE include
an OID column
The attached improves a document in src/backend/access/gin/README.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/backend/access/gin/README b/src/backend/access/gin/README
index 3f0c3e2..8a71d28 100644
--- a/src/backend/access/gin/README
+++ b/src/backend/access/gin/README
@@ -181,7 +181,7
The attached improves a comment in gin_private.h a little bit.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/include/access/gin_private.h b/src/include/access/gin_private.h
index 81a3bee..3aa4276 100644
--- a/src/include/access/gin_private.h
+++ b/src/include/access/gin_private.h
(2014/04/16 22:16), Hannu Krosing wrote:
On 04/16/2014 01:35 PM, Etsuro Fujita wrote:
Maybe I'm missing something, but I think that you can do what I think
you'd like to do by the following procedure:
No, what I'd like PostgreSQL to do is to
1. select the id+set from local table
2. select
)
Output: onemillion.id
- Seq Scan on public.onemillion (cost=0.00..20834.00
rows=99918 width=4)
Output: onemillion.id
Filter: (onemillion.data '0.9'::text)
Planning time: 0.215 ms
(14 rows)
Thanks,
Best regards,
Etsuro Fujita
--
Sent via
(2014/04/14 23:53), Robert Haas wrote:
On Fri, Apr 11, 2014 at 5:00 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Attached is an updated version of the patch.
I applied the first two hunks of this, which seem like clear
oversights; and also the bit fixing the constraint_name language
Attached is a small patch to improve create_foreign_table.sgml.
Thanks,
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 06a7087..4a8cf38 100644
--- a/doc/src/sgml/ref/create_foreign_table.sgml
+++ b/doc/src
(2014/04/09 12:03), Etsuro Fujita wrote:
(2014/04/09 1:23), Robert Haas wrote:
On Tue, Apr 8, 2014 at 5:05 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Attached is a patch to improve the manual page for the ALTER TABLE
command.
Do we really need to add a section for type_name when we
to do with the query_pathkeys.
I think that the two pathkeys would be proved to be equal, if the both
conditions are satisfied.
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
(2014/04/10 22:25), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
(2014/04/10 0:08), Tom Lane wrote:
TBH I think that's barely the tip of the iceberg of cases where this
patch will get the wrong answer.
Also, I don't see it doing anything to check the ordering
Attached is a patch to improve the manual page for the ALTER TABLE command.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/ref/alter_table.sgml
b/doc/src/sgml/ref/alter_table.sgml
index 0b08f83..ce67c71 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref
(2014/04/09 1:23), Robert Haas wrote:
On Tue, Apr 8, 2014 at 5:05 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Attached is a patch to improve the manual page for the ALTER TABLE command.
Do we really need to add a section for type_name when we already
have a section for OF type_name
as is. So, all we need to do is show important use
cases that prove the effectiveness of the patch. Sorry, I can't come up
with a good idea, though.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
||
569 relkind ==
RELKIND_FOREIGN_TABLE));
Is this intended to support an OID column on foreign tables in future?
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
information, the same assertion can be found in
create_foreignscan_plan().
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
and the gain by
the previous optimization don't seem to be significant..
Yeah, that's true. I have to admit that the previous optimization is
nonsense.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
compromise by putting a note to CF-app that last judgement
is left to committer.
OK So, if there are no objections of other, I'll mark this patch as
ready for committer and do that.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
(2014/03/20 21:59), Etsuro Fujita wrote:
Here is a simple example for the case where the
use_remote_estimate option is true:
Sorry, I incorrectly wrote it. The following example is for the case
where the option is *false*, as you see.
# On mydatabase
mydatabase=# CREATE TABLE mytable (id
,
Best regards,
Etsuro Fujita
*** a/contrib/file_fdw/file_fdw.c
--- b/contrib/file_fdw/file_fdw.c
***
*** 117,122 static void fileGetForeignRelSize(PlannerInfo *root,
--- 117,126
static void fileGetForeignPaths(PlannerInfo *root,
RelOptInfo
.
[1] http://www.postgresql.org/message-id/530c7464.6020...@lab.ntt.co.jp
Best regards,
Etsuro Fujita
*** a/contrib/file_fdw/file_fdw.c
--- b/contrib/file_fdw/file_fdw.c
***
*** 117,122 static void fileGetForeignRelSize(PlannerInfo *root,
--- 117,126
static void
be implemented as a separate patch.
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/02/18 12:37), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
(2014/02/18 12:03), Tom Lane wrote:
The calling FDW is supposed to do that; note the header comment.
However, ISTM postgresGetForeignPaths() doesn't work like
that. It uses the same rowcount for all paths
-table case
to reparameterize_path(). And I think we should introduce a new FDW
routine, say ReparameterizeForeignPath() because the processing would be
performed best by the FDW itself.
Comments are welcome!
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql
This is a small patch to improve comments in tablecmds.c. Please find
attached a patch.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
index 08b037e..ed9d206 100644
--- a/src/backend/commands/tablecmds.c
+++ b/src/backend
doesn't
seem to be a matter of 'ALTER TABLE'. Could you tell me how this
is related to 'ALTER TABLE'?
These are not related to ALTER TABLE. [NO] INHERIT parent_table (and
ADD/DROP CONSTRAINT) are what I think should be newly allowed to apply
to foreign tables directly.
Thanks,
Best regards,
Etsuro
(2014/02/20 19:55), Etsuro Fujita wrote:
(2014/02/20 15:47), Kyotaro HORIGUCHI wrote:
Although my concerns here are only two points,
unanticipated application and maintenancibility. I gave a
consideration on these issues again.
Sorry, I misunderstood what you mean by unanticipated
not sure it's worth implementing such a
checking mechanism in the recursive altering operation...
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/02/19 12:12), Kyotaro HORIGUCHI wrote:
At Tue, 18 Feb 2014 19:24:50 +0900, Etsuro Fujita wrote
From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
I'm not sure that allowing ALTER TABLE against parent table affects
descendants even some of them are foreign table. I think the rule
From: Shigeru Hanada [mailto:shigeru.han...@gmail.com]
2014-02-10 21:00 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/02/07 21:31), Etsuro Fujita wrote:
So, I've modified the patch so
that we continue to disallow SET STORAGE on a foreign table *in the
same manner as before
Why does create_foreignscan_path() not set the rowcounts based on
ParamPathInfo when the path is a parameterized path? Please find
attached a patch.
Thanks,
Best regards,
Etsuro Fujita
*** a/src/backend/optimizer/util/pathnode.c
--- b/src/backend/optimizer/util/pathnode.c
(2014/02/18 12:03), Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
Why does create_foreignscan_path() not set the rowcounts based on
ParamPathInfo when the path is a parameterized path?
The calling FDW is supposed to do that; note the header comment.
Understood. However
(2014/02/07 21:31), Etsuro Fujita wrote:
So, I've modified the patch so
that we continue to disallow SET STORAGE on a foreign table *in the same
manner as before*, but, as your patch does, allow it on an inheritance
hierarchy that contains foreign tables, with the semantics that we
Hi Hanada-san,
Sorry for the delay.
(2014/01/30 14:01), Shigeru Hanada wrote:
2014-01-27 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
While still reviwing this patch, I feel this patch has given enough
consideration to interactions with other commands, but found the following
incorrect
(2014/02/04 20:56), Robert Haas wrote:
On Sun, Feb 2, 2014 at 10:15 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Allowing ALTER COLUMN SET STORAGE on foreign tables would make sense if for
example, SELECT * INTO local_table FROM foreign_table did create a new
local table of columns
(2014/02/01 8:01), Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Thu, Aug 15, 2013 at 07:25:17PM +0900, Etsuro Fujita wrote:
Attached is an updated version of the patch. In that version the code for
the
newly added function build_function_pathkeys() has been made more simple
* INTO local_table FROM foreign_table did create a
new local table of columns having the storage types associated with
those of a foreign table?
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
(2014/01/28 22:01), Etsuro Fujita wrote:
(2014/01/27 21:49), Shigeru Hanada wrote:
Is it too big change that making ANALYZE command to handle foreign
tables too even if no table name was specified? IIRC, performance
issue was the reason to exclude foreign tables from auto-analyze
processing
(2014/01/27 21:49), Shigeru Hanada wrote:
2014-01-27 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/01/25 11:27), Shigeru Hanada wrote:
Yeah, the consistency is essential for its ease of use. But I'm not sure
that inherited stats ignoring foreign tables is actually useful for query
(ie ATSimpleRecursion())
should be modified for the ALTER COLUMN SET STORAGE case.
I just wanted to quickly tell you this for you to take time to consider.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
(2014/01/28 0:55), Atri Sharma wrote:
On 27-Jan-2014, at 21:03, David Fetter da...@fetter.org wrote:
On Mon, Jan 27, 2014 at 05:06:19PM +0900, Etsuro Fujita wrote:
Hi Hanada-san,
While still reviwing this patch, I feel this patch has given enough
consideration to interactions with other
(2014/01/25 11:27), Shigeru Hanada wrote:
2014/1/23 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
Shigeru Hanada wrote:
Though this would be debatable, in current implementation, constraints
defined on a foreign table (now only NOT NULL and CHECK are supported)
are not enforced during INSERT
not.
I'd like to vote for the idea of silently forcing any constraints on a
foreign-table into assertion mode. No new syntax and better documentation.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
at this patch more closely.
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
.
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
I ran into a typo in src/include/access/gin_private.h. Patch attached.
Thanks,
Best regards,
Etsuro Fujita
gin_private.h-typo.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
find attached a patch.
Thanks,
Best regards,
Etsuro Fujita
explain-bitmapscan-20140110.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas wrote:
On Mon, Jan 6, 2014 at 9:40 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp
wrote:
Thank you for taking time to look at this patch. The peak memory
usage for the discarded bitmap *can* be reflected in the number
displayed for the bitmap heap scan by the following code
Tom Lane wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp writes:
[ pathkey_and_uniqueindx_v7_20131203.patch ]
I started to look at this patch. I don't understand the reason for the
foreach loop in index_pathkeys_are_extensible (and the complete lack of
comments in the patch isn't helping
*/
if (a-nentries == 0)
return;
***
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://www.postgresql.org/mailpref/pgsql-hackers
be a overdone.
The following modification to v7 does this.
It seems to me that this would be reasonable at least as the first step and
that it would be better to leave more close checking for future work.
Thanks,
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers
.
Attached is a new version of the patch, which shows only fetch block
information and memory usage information. I'll add this to the upcoming CF.
Thanks,
Best regards,
Etsuro Fujita
explain-bitmapscan-20131227.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql
Peter Eisentraut wrote:
On 12/24/13, 1:33 AM, Etsuro Fujita wrote:
This is a small patch to fix a typo in src/backend/utils/mmgr/README.
I don't think that change is correct.
I've fixed the patch, though that might be still wrong. I'm not a native
English speaker ;). Please find attached
701 - 800 of 949 matches
Mail list logo
