x27;t handle
whole-row references (ie, attnum=0), in which case that would cause
cache lookup errors. Attached is a small patch to address this issue.
Best regards,
Etsuro Fujita
postgres-fdw-conv-error-callback.patch
Description: binary/octet-stream
--
Sent via pgsql-hackers mailing list (
On 2016/06/27 18:56, Ashutosh Bapat wrote:
On Mon, Jun 27, 2016 at 3:06 PM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
I found another bug in error handling of whole-row references in
join pushdown; conversion_error_callback fails to take into account
should read "whole row reference of
foreign table ft1".
OK, attached is an updated version of the patch, which uses "whole-row
reference", not "wholerow".
Best regards,
Etsuro Fujita
postgres-fdw-conv-error-callback-v3.patch
Description: binary/octet-stream
--
ched an updated version.
Best regards,
Etsuro Fujita
postgres-fdw-conv-error-callback-v4.patch
Description: binary/octet-stream
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
t to 0,
too. And ISTM that it's better that the core (ie, ForeignNext) supports
doing that, rather than each FDW does that work. That would also
minimize the overhead because ForeignNext does that if needed. Please
find attached a patch.
Best regards,
Etsuro Fujita
postgres-fdw-syscol-c
On 2016/07/02 0:32, Robert Haas wrote:
On Wed, Jun 29, 2016 at 1:38 AM, Ashutosh Bapat
wrote:
On Tue, Jun 28, 2016 at 12:52 PM, Etsuro Fujita
wrote:
Please find attached an updated version.
This looks good to me. Regression tests pass.
Committed. Thanks to Etsuro Fujita for the patch
Hi,
I noticed that the return type of IsForeignScanParallelSafe described in
fdwhandler.sgml isn't correct; that should be bool, not Size. Please
find attached a small patch for that.
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/fdwhandler.sgml b/doc/src/sgml/fdwhandler
On 2016/07/09 1:41, Tom Lane wrote:
Etsuro Fujita writes:
I noticed that the return type of IsForeignScanParallelSafe described in
fdwhandler.sgml isn't correct; that should be bool, not Size. Please
find attached a small patch for that.
Pushed, thanks!
Thank you.
Best regards,
E
ld make
people sloppy about creating user mappings, which could lead to latent
security problems [2].
Attached is a proposed patch for that.
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message-id/CA%2BTgmoZK6BB4RTb5paz45Vme%3Dq6Z3D7FF2-VKdVyQCS1ps-cGw%40mail.gmail.co
used as to what it should do when it sees a user mapping for an
FDW which says user mappings are meaningless.
The core wouldn't care about such a user mapping for the FDW; the core
would just ignore the user mapping. No?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hacker
RTEs are
equal in the case where user mappings are meaningless to the FDW, like
file_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
On 2016/07/15 11:48, Tom Lane wrote:
Etsuro Fujita writes:
One thing I'm not sure about is: should we insist that a join can be
pushed down only if the checkAsUser fields of the relevant RTEs are
equal in the case where user mappings are meaningless to the FDW, like
file_fdw?
If we
onsidering that user mapping OIDs now aren't available in RelOptInfos,
at least the former might be rather useless. Should we keep them in core?
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On 2016/07/21 16:30, Etsuro Fujita wrote:
One thing I'd like to discuss is GetUserMappingById/GetUserMappingId.
Though those functions aren't used in any places, I didn't take them
out, because I thought somebody else would need them someday. But
considering that user mapping
DWs; in the above example replace "Foreign Scan" with
"Foreign Join on public.ft1 t1, public.ft2 t2". Please find attached a
patch for that. Comments welcome!
Best regards,
Etsuro Fujita
explain-for-foreign-custom-join-pushdown.patch
Description: binary/octet-str
the "Relations" or
"Remote SQL" info printed by postgres_fdw. Maybe something like this:
Foreign Scan/Join on target relation(s)
Output: ...
Relations: ...
Additional Operations: grouping, aggregate, ...
Remote SQL: ...
That seems not that clumsy to me.
Best rega
- A flag to turn on/off printing relation(s) name
ISTM that the relation information should be always printed even in the
case of scanrelid=0 by the core, because that would be essential for
analyzing EXPLAIN results.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql
LAIN command attaches something like "on t0,t1,t2" after the GpuJoin
*with no choice*, it is problematic and misleading.
It shall be controllable by the extension which knows what tables are
actually scanned. (Please note that I never says extension makes the string.
It is a job of core exp
ern for you proposition is, ForeignScan/CustomScan node is
enforced to print name of underlying relations, regardless of its actual
behavior. The above GpuJoin never scans tables at least, thus, it mislead
users if we have no choice to print underlying relation names.
OK, I understand we would
On 2016/07/29 13:05, Etsuro Fujita wrote:
In a foreign-join case,
however, we can't see such relations from the EXPLAIN printed *by core*.
postgres_fdw avoids this issue by adding such relations to the EXPLAIN
using ExplainForeignScan as shown in the below example, but since such
relation
E ...
I think "Foreign Join" better indicates that foreign tables listed after
that (ie, foreign_table1 and foreign_table2 in the example) are joining
(or component) tables of this join, than "Foreign Scan".
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
We can see the remote names of the foreign tables from the catalogs, so
we would easily identify the local names of foreign tables in the remote
SQL and thus the join type (or join tree structure) from the SQL.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hac
ModifyTable approach.
Best regards,
Etsuro Fujita
fdw-query-planning.patch
Description: binary/octet-stream
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
es_fdw knows it is remote join. It is quite easy to tell the core
this ForeignScan node is "Join". Also, it knows which tables are involved in.
Yeah, we can do that.
We can add hint information to control relations name to be printed.
For foreign joins, it would make sense to add su
-scan/join operations? Are you saying EPQ recheck and
alternative local join plan?
No. I mean e.g., aggregation, window functions, sorting, or table
modification. In other words, Foreign Scan plan nodes created from
ForeignPath paths created from GetForeignUpperPaths.
Best regards,
Ets
On 2016/08/01 20:15, Etsuro Fujita wrote:
I thought about the Relations line a bit more and noticed that there are
cases where the table reference names for joining relations in the
Relations line are printed incorrectly. Here is an example:
postgres=# explain verbose select * from (select t1
able to apply on both of foreign-scan and
custom-scan, and no need to future maintenance if and when FDW gets support
remote Aggregation, Sort or others.
I'd like to discuss this issue separately, maybe in a new thread.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing
ture of CustomScan side to follow up FDW sooner or later.
However, we will have to apply a different manner on CustomScan side, or
overwrite
what you proposed on FDW side, at that time.
It is not a desirable future.
I agree on that point that it's better to handle both ForeignScan and
Custom
individual contributors in the same development areas.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2016/08/02 21:35, Etsuro Fujita wrote:
I removed the Relations line. Here is an updated version of the patch.
I revised code and comments a bit. Attached is an updated version of
the patch.
Best regards,
Etsuro Fujita
explain-for-foreign-join-pushdown-v2.patch
Description: binary
On 2016/08/05 21:47, Robert Haas wrote:
On Tue, Jul 26, 2016 at 11:20 PM, Etsuro Fujita
wrote:
I noticed that currently the core doesn't show any information on the target
relations involved in a foreign/custom join in EXPLAIN, by itself.
I think that's a feature, not a bug.
I
should not be done in
> AnalyzeForeignTable handler of each FDW because some FDW might forget to
> do it. Maybe it should be pulled up to analyze_rel or somewhere in core.
> - It should be mentioned in a document that foreign tables are not
> analyzed automatically because they are re
utomatic analyze" of foreign tables...
The patch does not analyze on foreign tables automatically. (The issue
of auto-analyze on foreign tables has been discussed. Please refer to [1].)
[1] http://archives.postgresql.org/pgsql-hackers/2011-09/msg00992.php
Best regards,
Etsuro Fujita
(2011/11/07 20:26), Shigeru Hanada wrote:
> (2011/10/20 18:56), Etsuro Fujita wrote:
>> I revised the patch according to Hanada-san's comments. Attached is the
>> updated version of the patch.
>>
>> Changes:
>>
>> * pull up of logging "analyzing
ow_acquirer considers those tuples as "dead" tuples. This is
for the consistency with NOT NULL constrain. (But I don't know why
fileIterateForeignScan routine allows such dead tuples. I may have
missed something.)
Best regards,
Etsuro Fujita
(2011/11/18 21:00), Shigeru Hanada
's for "foreign index scan" on CSV file data that I plan
to propose in the next CF. So, it is meaningless for now. I'm sorry.
I will fix it at the next version of the patch so that they don't have to.
Best regards,
Etsuro Fujita
--
Sent via pgsql-hackers mailing list
is less costly and widely applicable to the other DBMSs, while it,
of course, only works once we have statistics and/or index information
for foreign tables. But AFAIK we eventually want to have those, so I'd
like to propose to use the proposed approach until that time.
Best regards,
Etsu
(2011/11/28 20:50), Shigeru Hanada wrote:
> (2011/11/25 17:27), Etsuro Fujita wrote:
>>So, I think it might be better to estimate
>> such costs by pgsql_fdw itself without EXPLAINing on the assumption that
>> a remote postgres server has the sam
Hi Hanada-san,
I updated the patch. Please find attached a patch.
Best regards,
Etsuro Fujita
> (2011/11/18 21:00), Shigeru Hanada wrote:
>> (2011/11/18 16:25), Etsuro Fujita wrote:
>>> Thank you for your testing. I updated the patch according to your
>>> comment
(2011/12/14 15:34), Shigeru Hanada wrote:
> (2011/12/13 22:00), Etsuro Fujita wrote:
>> Thank you for your effectiveness experiments and proposals for
>> improvements. I updated the patch according to your proposals.
>> Attached is the updated version of the patch.
>
&g
ying function you added.
Sorry for the delay.
[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(PlannerIn
to update the
documentation further early next week.
Thanks,
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,
--- 1
(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
gt; foreign tables on alter table, if you belive it to be put off,
> I'll 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.
Th
gt;>> reasons?
>>
>> The reason is that we get the result of the recheck from
>> path->fdw_private. Sorry, I'd forgotten it. So, I modified the code to
>> simply call create_foreignscan_path().
>
> Anyway you new code seems closer to the basics and th
athlist().
For 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
ind == RELKIND_RELATION ||
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 y
atch is not so wide 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 mak
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
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"
roven *anything at all* about whether the
> index columns have something 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@po
(2014/04/10 22:25), Tom Lane wrote:
> Etsuro Fujita 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 any
(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
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
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/14 23:53), Robert Haas wrote:
On Fri, Apr 11, 2014 at 5:00 AM, Etsuro Fujita
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.
I think the other changes
0834.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 pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
(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
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/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 O
(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
wrote:
Attached is an updated version of the patch.
I think the other changes deserve to be considered separately, and in
particular I'm still not sure it
to think 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-ha
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/28 23:31), Robert Haas wrote:
On Thu, Apr 24, 2014 at 7:59 AM, Etsuro Fujita
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 it makes things better.
(2014/05/05 23:05), Robert Haas wrote:
On Wed, Apr 30, 2014 at 4:10 AM, Etsuro Fujita
wrote:
(2014/04/28 23:31), Robert Haas wrote:
On Thu, Apr 24, 2014 at 7:59 AM, Etsuro Fujita
wrote:
The patch attached improves docs in fdwhandler.sgml a little bit.
When you submit a patch, it&#
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 wit
901 - 967 of 967 matches
Mail list logo
