(2011/07/04 10:17), Shigeru Hanada wrote:
> (2011/07/03 18:50), Kohei KaiGai wrote:
>> I checked the per-column generic option patch.
>> Right now, I have nothing to comment on anymore.
>> So, it should be reviewed by committers.
>
> Thanks for the review!.
I w
- Invalid item names properly cause error.
* I'm not so familiar to pl/pgsql, but ISTM that enough cases are
considered about newly added diagnostics items.
* I didn't see any crash during my tests.
In conclusion, this patch still needs some effort to be "Ready for
Committer",
On Fri, 21 Jan 2011 18:28:19 +0200
Heikki Linnakangas wrote:
> On 18.01.2011 17:26, Shigeru HANADA wrote:
> > 3) 20110118-fdw_handler.patch - This patch adds support for HANDLER
> > option to FOREIGN DATA WRAPPER object.
>
> Some quick comments on that:
Thanks for th
35. Extending SQL"?
> In general, I think the design is sound. What we need is more
> documentation. It'd also be nice to see the postgresql_fdw brought back
> to shape so that it works against this latest version of the api patch.
I'll post FDW API patches which reflect comments first, and then I'll
rebase postgresql_fdw against them.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, 31 Jan 2011 22:00:55 +0900
Shigeru HANADA wrote:
> I'll post FDW API patches which reflect comments first, and then I'll
> rebase postgresql_fdw against them.
Sorry for late, attached are revised version of FDW API patches which
reflect Heikki's comments except re
sed version of file_fdw patch.
This patch is based on latest FDW API patches which are posted in
another thread "SQL/MED FDW API", and copy_export-20110104.patch which
was posted by Itagaki-san.
Regards,
--
Shigeru Hanada
file_fdw.patch.gz
Description: Binary data
--
Sent via pgsql-hac
On Mon, 7 Feb 2011 21:00:53 +0900
Itagaki Takahiro wrote:
> On Mon, Feb 7, 2011 at 16:01, Shigeru HANADA
> wrote:
> > This patch is based on latest FDW API patches which are posted in
> > another thread "SQL/MED FDW API", and copy_export-20110104.patch which
&
reaind/reading/
Recent file_fdw is available here:
http://git.postgresql.org/gitweb?p=users/hanada/postgres.git;a=summary
I'll submit revised file_fdw patch after removing IsForeignTable()
catalog lookup along Heikki's proposal.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailin
On Mon, 07 Feb 2011 09:37:37 +0100
Heikki Linnakangas wrote:
> On 07.02.2011 08:00, Shigeru HANADA wrote:
> > Sorry for late, attached are revised version of FDW API patches which
> > reflect Heikki's comments except removing catalog lookup via
> > IsForeignTable(
On Tue, 8 Feb 2011 08:49:36 -0500
Robert Haas wrote:
> On Tue, Feb 8, 2011 at 4:42 AM, Shigeru HANADA
> wrote:
> > I'll submit revised file_fdw patch after removing IsForeignTable()
> > catalog lookup along Heikki's proposal.
>
> So I'm a bit confused.
e/hanada/DB/BINARY/branches.bin' with binary;
COPY 9187201950435737481
It would be because DR_copy's processed is not initialized in
CreateCopyDestReceiver(). Please see attached patch.
Regards,
--
Shigeru Hanada
20110218_initialize_processed.patch
Description: Binary data
--
Sent vi
On Wed, 16 Feb 2011 16:48:33 +0900
Itagaki Takahiro wrote:
> On Tue, Feb 8, 2011 at 00:30, Shigeru HANADA
> wrote:
> > Fixed version is attached.
>
> I reviewed your latest git version, that is a bit newer than the attached
> patch.
> http://git.postgresql.o
2.
I'm working on it.
Fixes for new FDW API have been done, but there are some problems in
SQL generation codes, such as SELECT clause optimization (omitting
unused column from SELECT clause). It would take a while, but I'll
post revised version of the patch tomorrow.
Regards,
--
Shige
I noticed that CREATE FOREIGN TABLE document would need some
corrections.
- server_name is not mentioned in Parameters section
- "=" is unnecessary in OPTIONS
Please find attached a brief patch.
Regards,
--
Shigeru Hanada
create_foreign_table_doc.patch
Description: Binary data
CL_OBJECT_FOREIGN_TABLE),
but it wouldn't be problem because object type will be retrieved in
ExecGrant_Relation() for validate privilege type.
Probabry we should mention in GRANT documents that ALL TABLES
IN SCHEMA is considered to include foreign tables.
Attached patch includes removin
REATE TABLE with serial column is transformed into 3 DDLs:
(1) CREATE SEQUENCE, for serial column
(2) CREATE TABLE, skipped if table exists with same name
(3) ALTER SEQUENCE OWNED BY, associate sequence with table
This error occurs in (3) because process_owned_by() misunderstand
th
2011/4/2 Robert Haas :
> On Fri, Apr 1, 2011 at 11:57 AM, Thom Brown wrote:
>> Should we also have support for comments on user mappings?
>
> Oh, bugger. Yeah, probably.
I'd work on this, if taking some days is OK.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers
On Sun, 3 Apr 2011 10:51:04 +0900
Shigeru Hanada wrote:
> 2011/4/2 Robert Haas :
> > On Fri, Apr 1, 2011 at 11:57 AM, Thom Brown wrote:
> >> Should we also have support for comments on user mappings?
> >
> > Oh, bugger. Yeah, probably.
>
> I'd work
Thanks for the review.
On Mon, 4 Apr 2011 12:47:18 -0400
Robert Haas wrote:
> On Mon, Apr 4, 2011 at 6:49 AM, Shigeru HANADA
> wrote:
> > 1) Who can comment on a user mapping?
> > Basically only the owner can comment on a object, but user mappings
> > don't have o
On Tue, 05 Apr 2011 13:37:48 +0900
Shigeru HANADA wrote:
> On Mon, 4 Apr 2011 12:47:18 -0400
> Robert Haas wrote:
> > BTW, I think you can merge patches 0001 to 0004 into a single patch.
>
> They were separated just for review, so I'll post revised and unified
>
ERT, pg_lesslog generates incremental logs
such as xl_heap_header and tuple image from the inserted tuple in the
full-page image, and replaces full-page image with them.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
ign table as a child node of Append
Currently prepunion.c assumes that children of Append have
RELKIND_RELATION as relkind always, so we need to set relkind of child
RTE explicitly.
Please see attached PoC patch. I'll enhance implementation, tests and
document and submit the patch for the next
define "foreign
index" on foreign tables to indicate which column combination is
reasonably sortable.
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
use dblink. For better or worse, the FDW stuff is
> following the SQL standard's SQL/MED design, which does not do it
> like that.
Pass-through mode mentioned in SQL/MED standard might be what he wants.
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
commit
784e762e886e6f72f548da86a27cd2ead87dbd1c (committed on 2013-11-21)
allows FunctionScan node to have multiple function expression, so Node
* funcexpr in CustomScan should be List *funcitons now.
I'll continue to review by applying patches onto 2013-11-19 HEAD.
--
Shigeru HANADA
--
Sen
Hi Merlin,
2013/11/22 Merlin Moncure :
> On Thu, Nov 21, 2013 at 6:43 PM, Shigeru Hanada
> wrote:
>> 2013/11/22 Tom Lane :
>>> Merlin Moncure writes:
>>>> On Thu, Nov 21, 2013 at 9:05 AM, Bruce Momjian wrote:
>>>>> I know join pushdowns s
low new syntax like WITH alias AS FOREIGN VIEW
(remote query)?
I think it's nice to support executing ad-hoc remote query written in
the syntax which is valid only on remote data source through FDW, and
at the moment dblink interface seems feasible for that purpose.
--
Shigeru HANADA
--
lation and
has_wholerow_reference seem to be useful for other FDWs. Is it able
to move them into core?
(4) postgres_fdw estimates costs of join by calculating local numbers.
How about to support remote estimation by throwing EXPLALAIN query
when use_remote_estimates = true.
--
Shigeru HANA
2013/11/29 Kohei KaiGai :
> I merged all the propositions from Jim. Thanks, it made the documentation
> quality better. Also, I fixed up cosmetic stuff around whitespace <-> tab.
I found some typos in documents and comments. Please see attached
patch for detail.
--
Sh
ames used in the join or the scan would help users to
understand what is going on in Custom Scan.
Regards,
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi Kaigai-san,
2013/12/11 Kohei KaiGai :
> 2013/12/10 Shigeru Hanada :
>> The patches could be applied cleanly, but I saw a compiler warning
>> about get_rel_relkind() in foreign.c, but it's minor issue. Please
>> just add #include of utils/lsyscache.h there.
>>
KaiGai-san,
2013/12/16 KaiGai Kohei :
> (2013/12/16 14:15), Shigeru Hanada wrote:
>> (1) ctidscan
>> Is session_preload_libraries available to enable the feature, like
>> shared_*** and local_***? According to my trial it works fine like
>> two similar GUCs.
>>
before, N-way (not only 2-way) joins should be supported in
the first version by construct SELECT SQL by containing source query
in FROM clause as inline views (a.k.a. from clause subquery).
2014-12-26 13:48 GMT+09:00 Shigeru Hanada :
> 2014-12-16 1:22 GMT+09:00 Robert Haas :
>> On Mon, Dec
ion?
>
> Thanks,
> --
> NEC OSS Promotion Center / PG-Strom Project
> KaiGai Kohei
>
>
>> -Original Message-
>> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Shigeru Hanada
>> Sent: Monday, Februa
> A few functions added in src/backend/foreign/foreign.c are not
> called by anywhere, at this moment.
>
> create_plan_recurse() is reverted to static. It is needed for custom-
> join enhancement, if no other infrastructure can support.
I made it back to static because I tho
nPaths() to keep the policy that all
interface between core and FDW should be in FdwRoutine, instead of
using hook function. Now I'm writing document about it, and will post
it in a day.
2015-02-19 16:19 GMT+09:00 Shigeru Hanada :
> 2015-02-17 10:39 GMT+09:00 Kouhei Kaigai :
>> Let me put
stgres_fdw.
> Another issue:
>
> # EXPLAIN VERBOSE SELECT NULL FROM (SELECT people.id FROM people INNER JOIN
> countries ON people.country_id = countries.id LIMIT 3) x;
> ERROR: could not open relation with OID 0
Good catch. In my quick trial, removing LIMIT3 avoids this error.
I&#x
s in a query. Do you have a good idea?
I'd like to vote for keeping current aliasing style, use "l" and "r"
for join source relations, and use a_0, a_1, ... for each column of
them.
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
gt; at postgres_fdw.c:3293
> #1 0x008e51d6 in errfinish (dummy=0) at elog.c:436
> #2 0x008935cd in tidin (fcinfo=0x7fffc257e8a0) at tid.c:69
> /home/kaigai/repo/sepgsql/src/backend/utils/adt/tid.c:69:1734:beg:0x8935cd
> (gdb) p str
> $6 = 0x1d17cf7 "foo"
Join push-down underlying UPDATE or DELETE requires ctid as its
output, but it seems not fully supported. I'm fixing this issue now.
Regards,
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ehalf Of Kouhei Kaigai
>> Sent: Tuesday, March 03, 2015 6:31 PM
>> To: Kaigai Kouhei(海外 浩平); Robert Haas
>> Cc: Tom Lane; pgsql-hackers@postgreSQL.org; Shigeru Hanada
>> Subject: Re: Custom/Foreign-Join-APIs (Re: [HACKERS] [v9.5] Custom Plan API)
>>
>> The attach
I adjusted the condition to check scanrelid instead.
>>
>> Is this issue fixed by v5 custom/foreign join patch?
>>
> Yes, please rebase it.
>
> --
> NEC OSS Promotion Center / PG-Strom Project
> KaiGai Kohei
>
--
Shigeru HANADA
foreign_join_v3.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
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.
>
>
> Thanks for the work, Hanada-san and KaiGai-san!
>
> Maybe I
rs t where t.bid = b.bid and t.tid < 10;
ERROR: ctid is NULL
2015-03-03 21:34 GMT+09:00 Shigeru Hanada :
> I rebased "join push-down" patch onto Kaigai-san's Custom/Foreign Join
> v6 patch. I posted some comments to v6 patch in this post:
>
> http://www.postgresql
t; --
> Foreign Scan (cost=100.00..132.00 rows=2560 width=8)
>Output: (val + val2)
>Remote SQL: SELECT r.a_0, r.a_1 FROM (SELECT val, NULL FROM public.lt) l
> (a_0, a_1) INNER JOIN (SELECT val, val2 FROM public.lt) r (a_0, a_1) ON ((
> (r.a
ssues from Kaigai-san and Ashutosu, whole-row
reference handling and use of get_joinrel_parampathinfo().
2015-03-05 22:00 GMT+09:00 Shigeru Hanada :
> Hi Ashutosh, thanks for the review.
>
> 2015-03-04 19:17 GMT+09:00 Ashutosh Bapat :
>> In create_foreignscan_path() we have lines li
remote might require whole planner to run for the join
subtree.
Regards,
--
Shigeru HANADA
join_pushdown.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
2014-12-16 0:45 GMT+09:00 Tom Lane :
> Shigeru Hanada writes:
>> I'm working on $SUBJECT and would like to get comments about the
>> design. Attached patch is for the design below. Note that the patch
>> requires Kaigai-san's custom foriegn join patch[1]
>
>
2014-12-16 1:22 GMT+09:00 Robert Haas :
> On Mon, Dec 15, 2014 at 3:40 AM, Shigeru Hanada
> wrote:
>> I'm working on $SUBJECT and would like to get comments about the
>> design. Attached patch is for the design below.
>
> I'm glad you are working on this.
&
e misread...)
Could you tell me little more detail why it doesn't make sense to have
table reloptions separate from table FDW options?
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
T for DROP.
But at this time it would break backward compatibility. I think it's
reasonable to unify the syntax for handling SQL/MED options at every
level to "OPTIONS (key 'value', ...)".
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-h
(2011/07/12 21:19), Robert Haas wrote:
> On Jul 12, 2011, at 12:31 AM, Shigeru Hanada wrote:
>> I'm afraid that I've misunderstood the discussion. Do you mean that
>> per-table options should be stored in reloptions, but per-column should
>> be separated from att
(2011/07/12 22:56), Alvaro Herrera wrote:
> Speaking of which -- what's the difference between ADD and SET for SQL/MED
> options?
ADD can only add new option; it can't overwrite existing option's value.
To overwrite existing option's value, you need to use SET inst
SET (key = value, ...)".
Without syntax unification, some tools should care relkind before
handling attoptions. For instance, pg_dump should choose syntax used to
dump attoptions. It seems undesired complexity.
Any comments/objections/questions are welcome.
Regards,
--
Shigeru Hanada
*
So it would be
worth documenting that subplan's RescanForeignScan will be also called
before first IterateForeignScan call.
I'm planning to propose enhancement of FDW API in next CF for 9.2
release, so your comments are very valuable.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-h
I noticed that psql document wrongly says that \d+ command shows
per-table FDW options of a foreign table, but in fact, per-table FDW
options are shown only in the result of \det+ command. Attached patch
removes this wrong description.
This fix should be applied to 9.1 too.
Regards,
--
Shigeru
Sorry, I've missed sending copy to list, so I quoted off-list discussion.
> On Aug 5, 2011, at 7:59 PM, Shigeru Hanada
wrote:
>
>> 2011/8/6 Robert Haas:
>>> Done.
>>
>> Thanks!
>>
>>> Incidentally, I notice that if you do:
>>>
>&g
umn's name in force_not_null option of COPY
FROM. Default value is false.
The patch includes changes for code, document and regression tests. Any
comments/questions are welcome.
Regards,
--
Shigeru Hanada
diff --git a/contrib/file_fdw/data/text.csv b/contrib/file_fdw/data/text.csv
index
(2011/07/29 17:37), Shigeru Hanada wrote:
> I also attached a rebased version of force_not_null patch, which adds
> force_not_null option support to file_fdw. This is a use case of
> per-column FDW option.
[just for redirection]
Robert has committed only per_column_option patch. So
ecause former doesn't shows more
information than simple \d.
> BTW, I haven't bothered setting up
> functioning foreign tables yet, but is "Size" always going to be 0
> bytes in \dE+?
Yes, "Size" is total file size calculated
(2011/08/09 1:16), Robert Haas wrote:
> 2011/8/8 Shigeru Hanada:
>>>> Currently table-level options are showin in result of \det+ command
>>>> (only verbose mode), in same style as fdw and foreign servers.
>>>>
>>>> But \d is more popular for t
(2011/08/12 0:48), Robert Haas wrote:
> 2011/8/9 Shigeru Hanada:
>> postgres=# \d pgbench_accounts
>>Foreign table "public.pgbench_accounts"
>> Column | Type | Modifiers |Options
>> --+---+---+--
tree as a leaf node. In other words, joined
foreign tables are merged into upper ForeignJoin node.
Any comments are welcome.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
pefully post proof patch
for next CF.
BTW, Is adding foreign server oid to RelOptInfo acceptable? This field
is set in build_simple_rel() or build_join_rel() if the RelOptInfo
itself is a foreign scan, or it is a foreign join and both inner and
outer RelOptInfo have same and valid foreign serve
query tests
> --- 118,126
> word1 | word2
>---+---
> 123 | 123
> + abc | abc
> ABC | ABC
> NULL |
>(4 rows)
>
>-- basic query tests
>
> ==========
In my usual environment that test passed,
ing
used in file_fdw is affected from something unexpected, without
collation or locale setting?
BTW, I found a thread which is related to this issue.
http://archives.postgresql.org/pgsql-hackers/2011-09/msg00130.php
I changed the test data so that it uses only upper case alphabets,
because case d
ence
> NameStr(attr->attname) across ReleaseSysCache().
> I'd like to suggest to supply a copied attname using pstrdup for makeString
Oops, fixed.
[ I should check some of my projects for this issue... ]
Attached patch also includes some cosmetic changes such as removing
useless
//wiki.postgresql.org/wiki/Reviewing_a_Patch
And it would be easy to use git to follow changes made by other
developers in master branch.
http://wiki.postgresql.org/wiki/Working_with_Git
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
are enough small for this workaround.
Anyway, I'm going to publish recent pgsql_fdw for 9.1 on PGXN or
elsewhere, though it needs some (hopefully little) time.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
unnecessary.
In addition, documents about how to use the statistics would be
necessary, maybe in "23.1.5. The Autovacuum Daemon".
I'll set the status of this patch to waiting-on-author. Would you rebase
the patch and post it again?
Regards,
--
Shigeru Hanada
diff --git a/src/backend/
fdw.
Since per-column FDW options patch has been committed in last CF, It's
not hard to implement colname FDW option for pgsql_fdw, and rough
implementation has been already done. In next post you will be able to
map column names. :)
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
escape and null?
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
that result and lt3 should be joined with
one of local join methods, such as merge join and hash join.
I'll try your example soon.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
At a quick glance, this patch seems to have an issue about priority.
Which value is used if an option has been set both on a foreign table
and a foreign server?
Also I think documents and regression tests would be required for
this kind of change.
Regards,
--
Shigeru Hanada
--
Sent via pgsql
document that foreign tables are not
analyzed automatically because they are read-only.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thank for your comments.
2015-05-21 23:11 GMT+09:00 Robert Haas :
> On Sat, May 16, 2015 at 9:04 AM, Shigeru Hanada
> wrote:
>> d) All relations must have the same effective user id
>> This check is done with userid stored in PgFdwRelationInfo, which is
>> valid only w
stgres_fdw case. If this assumption is correct,
we need a mapping between a local ordinary table and a foreign table which
points remote replicated table.
--
Shigeru HANADA
shigeru.han...@gmail.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
(2011/10/25 19:15), Magnus Hagander wrote:
> 2011/10/25 Shigeru Hanada:
>> I'd like to propose pgsql_fdw, FDW for external PostgreSQL server, as a
>> contrib module. I think that this module would be the basis of further
>> SQL/MED development for core, e.g. join-pus
ode, using multiple cursors concurrently through one connection
is OK. In SELECT mode, pgsql_fdw executes SELECT statement with
PQexecParams and retrieves whole result *inside* the first Iterate call for
an outer tuple. So libpq connection is already available when another scan
needs to call Iter
otocol portals (instead of
> executing a lot of FETCH commands) would help. But I think we'd be well
> advised to do the first pass with just the existing libpq facilities,
> and then measure to see where to improve performance.
I long for protocol-level cursor. :)
--
Shigeru Hanada
As you say, such design requires FDWs to skip some
records, but it would be difficult for some FDW (e.g. twitter_fdw) which
can't pick sample data up easily. IMHO such problem *must* be solved by
FDW itself.
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
which assume that foreign tables have system
columns).
If there seems to be a consensus on removing system column from foreign
tables, I'd like to work on this issue. Attached is a halfway patch,
and ISTM there is no problem so far.
Regards,
--
Shigeru Hanada
diff --git a/contrib/file_fdw/inp
o so.
- Some comment lines go past 80 columns.
- Some headers included in file_fdw.c seems unnecessary.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
27;t have it at the moment, I'll fix pgsql_fdw so that
it pushes down only built-in operators, including scalar-array operators.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
er.
Planner will be able to consider merge join without local sort with such
information. Without foreign index, we have to enumerate possible sort
keys with Blute-Force approach for same result, as mentioned by
Itagaki-san before.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hacker
ble can keep collation
consistent between foreign and local, like data type of column. We need to
support per-column-collation on foreign tables too, or should deny pushing
down condition which is collation-sensitive...
Regards,--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
inherited" for foreign tables' for that case?
Typo
Typo "spcify" is in document of analyze.
Regards,
--
Shigeru Hanada
postgres=# explain select * from csv_accounts where aid = 1;
QUERY PLAN
uot;pushdown=true" for efficiency.
If a condition contains any columns with pushdown=false, that condition
should NOT be pushed down.
This idea is only for pgsql_fdw now, but it can be used for other FDWs
which support push-down, and it would be also useful for ORDER BY
push-down support in
n that.
It's interesting viewpoint to think operator notation is syntax sugar of
function notation, e.g. "A = B" -> "int4eq(A, B)". Routine mappings
seem to work for operators too.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
we define it
as "all operations which might handle any collation-sensitive element",
all functions/operators which take any of character data types (text,
varchar, bpchar, sql_identifier, etc.) are unable to be pushed down.
Regards,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list
primarily,
> however, things to do is similar. We may need to revisit the Hanada-san's
> proposition in the past.
I can't recall the details soon but the reason I gave up was about
introducing ForiegnJoinPath node, IIRC. I'll revisit the discussion
and my proposal.
--
Shigeru
dynamic background workers
can request notification
LOG: redirecting log output to logging collector process
HINT: Future log output will appear in directory "pg_log".
Attached patch fixes this issue. Please apply onto HEAD and 9.4.
--
Shigeru HANADA
fix_worker_spi.patch
Descrip
he pool completely as a server-specific configuration.
Connection management seems FDW-specific feature to me. How about to
add FDW option, say pool_connection=true|false, to postgres_fdw which
allows per-server configuration?
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-h
201 - 292 of 292 matches
Mail list logo
