Re: [Proposal] Table partition + join pushdown

Hello, KaiGai-san.

Thank you for your comment, and sorry for late response.

> If inner-scan of the join under the append node has param_info, its qualifier shall be implicitly attached to the scan node. So, if it is legal, I'd like to have this approach because it is less invasive than enhancement of Hash node.
>
> You mention about copyObject() to make a duplication of underlying scan-path.
> Actually, copyObject() support is not minimum requirement, because all you need to do here is flat copy of the original path-node, then put param_info.
> (Be careful to check whether the original path is not parametalized.)

OK. I'll try implementation by a method you mentioned.

Best regards,
--
Taiki Kondo

NEC Solution Innovators, Ltd.

-----Original Message-----
From: Kaigai Kouhei(海外 浩平) [mailto:kaigai(at)ak(dot)jp(dot)nec(dot)com]
Sent: Wednesday, September 30, 2015 11:19 PM
To: Kondo Taiki(近藤 太樹)
Cc: Iwaasa Akio(岩浅 晃郎); pgsql-hackers(at)postgresql(dot)org
Subject: RE: [HACKERS] [Proposal] Table partition + join pushdown

> > * Suppose we focus on only HashJoin in the first version?
> > This patch also add support on NestLoop and MergeJoin, however,
> > NestLoop has no valuable scenario without parallel execution
> > capability, and the most valuable scenario on MergeJoin is reduction of rows prior to Sort.
> > Once input rows gets sorted, it is less attractive to filter out rows.
>
> I agree that handling for NestLoop doesn't make sense in this timing.
> But I think that handling for MergeJoin still makes sense in this timing.
>
> In my v1 patch, I implemented that the additional filter is used for
> qualification at same place as join filter, same as NestLoop.
> It is not useful indeed. I agree with you at this point.
>
> I think, and you also mentioned, large factor of cost estimation for
> MergeJoin is Sort under MergeJoin, so I believe additional filtering
> at Sort is a good choice for this situation, as same way at Hash under
> HashJoin.
>
> Furthermore, I think it is better way that the additional filtering
> shall be "added" to Scan node under each child (pushed-down) Join
> nodes, because we don't have to implement additional qualification at
> Join nodes and we only have to implement simply concatenating original
> and additional RestrictInfos for filtering.
>
> As a mere idea, for realizing this way, I think we have to implement
> copyObject() for Scan path nodes and use ppi_clauses for this usage.
>
> What is your opinion?
>

You are saying this part at create_scan_plan(), aren't you.

/*
* If this is a parameterized scan, we also need to enforce all the join
* clauses available from the outer relation(s).
*
* For paranoia's sake, don't modify the stored baserestrictinfo list.
*/
if (best_path->param_info)
scan_clauses = list_concat(list_copy(scan_clauses),
best_path->param_info->ppi_clauses);

If inner-scan of the join under the append node has param_info, its qualifier shall be implicitly attached to the scan node. So, if it is legal, I'd like to have this approach because it is less invasive than enhancement of Hash node.

You mention about copyObject() to make a duplication of underlying scan-path.
Actually, copyObject() support is not minimum requirement, because all you need to do here is flat copy of the original path-node, then put param_info.
(Be careful to check whether the original path is not parametalized.)

ParamPathInfo is declared as below:

typedef struct ParamPathInfo
{
NodeTag type;

Relids ppi_req_outer; /* rels supplying parameters used by path */
double ppi_rows; /* estimated number of result tuples */
List *ppi_clauses; /* join clauses available from outer rels */
} ParamPathInfo;

You may need to set the additional filter on ppi_clauses, number of rows after the filtering on ppi_rows and NULL on ppi_req_outer.
However, I'm not 100% certain whether NULL is legal value on ppi_req_outer.

If somebody can comment on, it is helpful.

> > * MultiExecHash() once put slot on outer_slot then move it to
> > inner_slot This patch add set_hash_references() to replace varno in
> > the expression of Hash->filterqual to OUTER_VAR. Why not INNER_VAR?
> > If Var nodes would be initialized t oreference inner_slot, you don't
> > need to re-assign slot.
>
> The node under Hash node is connected as the OUTER node. This
> implementation may be from implementation of
> set_dummy_tlist_references() commonly used by Material, Sort, Unique,
> SetOp, and Hash.
>
> And I was faced a problem when I was implementing EXPLAIN for the additional filter.
> I implemented same as you mentioned above, then error occurred in running EXPLAIN.
> I think EXPLAIN expects expression's varno is same as the position
> that the under node is connected to; i.e. if it is connected to OUTER,
> varno must be OUTER_VAR.
>
Ah, OK. It is a trade-off matter, indeed.

> > It seems to me it is not a fair estimation because inner_path_rows
> > means number of rows already filtered out, but filter_qual shall be
> > applied to all the inner input rows.
>
> OK. I'll fix it.
>
>
> Best regards,
> --
> Taiki Kondo
>
> NEC Solution Innovators, Ltd.
>
>
>
> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Kouhei Kaigai
> Sent: Tuesday, September 29, 2015 11:46 AM
> To: Taiki Kondo
> Cc: Akio Iwaasa; pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] [Proposal] Table partition + join pushdown
>
> > -----Original Message-----
> > From: pgsql-hackers-owner(at)postgresql(dot)org
> > [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Taiki Kondo
> > Sent: Thursday, September 24, 2015 8:06 PM
> > To: Kaigai Kouhei(海外 浩平)
> > Cc: Iwaasa Akio(岩浅 晃郎); pgsql-hackers(at)postgresql(dot)org
> > Subject: Re: [HACKERS] [Proposal] Table partition + join pushdown
> >
> > Hello, KaiGai-san.
> >
> > Thank you for your comment, and sorry for late response.
> >
> > The attached patch is completely rewritten from previous patch[1],
> > at your suggestion[2].
> > Please find attached.
> >
> Thanks for your work, and let me introduce purpose of the work
> briefly, because the last submission was August.
>
> His work intends (1) to save resource consumption on tables join at
> this moment, and (2) to provide an infrastructure of one parallel join
> scenario once Funnel node gets capable.
>
> Even if we construct partition tables, it is unavailable to utilize to
> filter out candidate rows of join. In the result, size of Hash table
> may grow more than necessity and it causes unnecessary nBatch increase.
>
> Below is the scenario this project tries to tackle. In case when
> tables join takes partitioned table on one side, usually, we once need
> to run entire partitioned table unless we cannot drop particular child tables.
>
> XXXXJoin cond (x = y)
> -> Append
> -> SeqScan on tbl_child_0 ... CHECK (hash_func(x) % 4 = 0)
> -> SeqScan on tbl_child_1 ... CHECK (hash_func(x) % 4 = 1)
> -> SeqScan on tbl_child_2 ... CHECK (hash_func(x) % 4 = 2)
> -> SeqScan on tbl_child_3 ... CHECK (hash_func(x) % 4 = 3)
> -> Hash
> -> SeqScan on other_table
>
> However, CHECK() constraint assigned on child tables give us hint
> which rows in other side are never related to this join.
> For example, all the rows in other_table to be joined with tbl_child_0
> should have multiple number of 4 on hash_func(y). We may be able to
> omit unrelated rows from the hash-table in this case, then it
> eventually allows to reduce the size of hash table.
>
> In case of INNER_JOIN, we can rewrite the query execution plan as below.
>
> Append
> -> HashJoin cond (x = y)
> -> SeqScan on tbl_child_0
> -> Hash ... Filter: hash_func(y) % 4 = 0
> -> SeqScan on other_table
> -> HashJoin cond (x = y)
> -> SeqScan on tbl_child_1
> -> Hash ... Filter: hash_func(y) % 4 = 1
> -> SeqScan on other_table
> -> HashJoin cond (x = y)
> -> SeqScan on tbl_child_2
> -> Hash ... Filter: hash_func(y) % 4 = 2
> -> SeqScan on other_table
> -> HashJoin cond (x = y)
> -> SeqScan on tbl_child_3
> -> Hash ... Filter: hash_func(y) % 4 = 3
> -> SeqScan on other_table
>
> Unrelated rows of Hash table is preliminarily, it allows to avoid hash
> table split when its size reaches to work_mem limitation.
>
> This join-pushdown is valuable on hash-join and merge-join if MJ takes
> unsorted relation and number of rows to be sorted is performance factor.
> Also, once Funnel gets capable to run Append on background worker, it
> is also helpful to run NestLoop in parallel.
>
> How about the opinion from third parties? I'm a bit biased, of course.
>
>
> OK, below is the brief comment to patch.
>
> * Suppose we focus on only HashJoin in the first version?
> This patch also add support on NestLoop and MergeJoin, however,
> NestLoop has no valuable scenario without parallel execution
> capability, and the most valuable scenario on MergeJoin is reduction of rows prior to Sort.
> Once input rows gets sorted, it is less attractive to filter out rows.
>
> * MultiExecHash() once put slot on outer_slot then move it to
> inner_slot This patch add set_hash_references() to replace varno in
> the expression of Hash->filterqual to OUTER_VAR. Why not INNER_VAR?
> If Var nodes would be initialized t oreference inner_slot, you don't
> need to re-assign slot.
>
> I'll try to have deeper investigation, later.
>
> > This patch contains following implementation, but I can't determine
> > this is correct or wrong.
> >
> > 1. Cost estimation
> > In this patch, additional row filter is implemented for Hash, Merge
> > join and
> Nested
> > Loop.
> > I implemented cost estimation feature for this filter by watching
> > other parts of filters, but I am not sure this implementation is
> > correct.
> >
>
> @@ -2835,6 +2864,8 @@ final_cost_hashjoin(PlannerInfo *root, HashPath *path,
> * not all of the quals may get evaluated at each tuple.)
> */
> startup_cost += qp_qual_cost.startup;
> + startup_cost += filter_qual_cost.startup +
> + filter_qual_cost.per_tuple * inner_path_rows;
> cpu_per_tuple = cpu_tuple_cost + qp_qual_cost.per_tuple;
> run_cost += cpu_per_tuple * hashjointuples;
>
> It seems to me it is not a fair estimation because inner_path_rows
> means number of rows already filtered out, but filter_qual shall be
> applied to all the inner input rows.
>
>
> > 2. Workaround for failing assertion at allpaths.c In
> > standard_join_search(), we expect to have a single rel at the final level.
> > But this expectation is disappointed by join pushdown feature,
> > because this
> will
> > search for the combinations not searched by original
> > standard_join_serch() at the final level. Therefore, once trying
> > join pushdown is succeeded, failing assertion occurs in allpaths.c.
> >
> > So I implemented workaround by temporary set NULL to
> > root->join_rel_level while trying join pushdown, but I think this implementation may be wrong.
> >
> It is my off-list suggestion. The standard_join_search expects root of
> the partition tables will appear, but child tables are out of scope.
> Once we try to push down the join under the append, we need to
> consider table joins between inner table and every outer child tables,
> however, it should not be visible to standard_join_search context.
> From the standpoint of standard_join_search, it get an AppendPath that
> represents a table join A and B, even if A contains 100 children and
> join was pushed down on behalf of the AppendPath.
> So, it is a reasonable way to set NULL on root->join_rel_level to
> avoid unexpected RelOptInfo addition by build_join_rel().
> "to avoid assertion" is one fact, however, intension of the code is
> avoid pollution of the global data structure. ;-)
>
>
> > 3. Searching pathkeys for Merge Join When join pushdown feature
> > chooses merge join for pushed-down join operation, planner fails to
> > create merge join node because it is unable to find pathkeys for
> > this merge join. I found this is caused by skipping child table in
> > finding pathkeys.
> >
> > I expect that it is for making planner faster, and I implemented
> > that planner doesn't skip child table in finding pathkeys for merge join.
> > But I am not sure this expectation is correct.
> >
> I like to recommend to omit MergeJoin support at the first version.
>
> Thanks,
>
> > Any comments/suggestions are welcome.
> >
> >
> > Remarks :
> > [1]
> >
> http://www.postgresql.org/message-id/12A9442FBAE80D4E8953883E0B84E0885
> C01FD@
> > BPXM01GP.gisp.nec.co.jp
> > [2]
> >
> http://www.postgresql.org/message-id/9A28C8860F777E439AA12E8AEA7694F80
> 11345B
> > 6(at)BPXM15GP(dot)gisp(dot)nec(dot)co(dot)jp
> >
> > Best regards,
> > --
> > Taiki Kondo
> >
> > NEC Solution Innovators, Ltd.
> >
> > -----Original Message-----
> > From: Kaigai Kouhei(海外 浩平) [mailto:kaigai(at)ak(dot)jp(dot)nec(dot)com]
> > Sent: Tuesday, August 18, 2015 5:47 PM
> > To: Kondo Taiki(近藤 太樹); pgsql-hackers(at)postgresql(dot)org
> > Cc: Iwaasa Akio(岩浅 晃郎)
> > Subject: RE: [Proposal] Table partition + join pushdown
> >
> > Hello Kondo-san,
> >
> > I briefly checked your patch. Let me put some comments about its
> > design and implementation, even though I have no arguments towards
> > its concept. :-)
> >
> > * Construction of RelOptInfo
> >
> > In your patch, try_hashjoin_pushdown() called by try_hashjoin_path()
> constructs
> > RelOptInfo of the join-rel between inner-rel and a subpath of Append
> > node. It is entirely wrong implementation.
> >
> > I can understand we (may) have no RelOptInfo for the joinrel between
> > tbl_child_0 and other_table, when planner investigates a joinpath to
> > process
> join
> > Append path with the other_table.
> >
> > > HashJoin
> > > -> Append
> > > -> SeqScan on tbl_child_0
> > > -> SeqScan on tbl_child_1
> > > -> SeqScan on tbl_child_2
> > > -> SeqScan on tbl_child_3
> > > -> Hash
> > > -> SeqScan on other_table
> > >
> > How about these alternatives?
> >
> > - calls make_join_rel() to the pair of tbl_child_X and other_table
> > by try_hashjoin_pushdown() or somewhere. make_join_rel() internally
> > construct a RelOptInfo for the supplied pair of relations, so
> > relevant RelOptInfo shall be properly constructed.
> > - make_join_rel() also calls add_paths_to_joinrel() towards all the
> > join logic, so it makes easier to support to push down other join
> > logic including nested-loop or custom-join.
> > - It may be an idea to add an extra argument to make_join_rel() to
> > inform expressions to be applied for tuple filtering on
> > construction of inner hash table.
> >
> > * Why only SeqScan is supported
> >
> > I think it is the role of Hash-node to filter out inner tuples
> > obviously unrelated to the join (if CHECK constraint of outer
> > relation gives information), because this join-pushdown may be able to support multi-stacked pushdown.
> >
> > For example, if planner considers a path to join this Append-path
> > with another relation, and join clause contains a reference to X?
> >
> > > Append
> > > -> HashJoin
> > > -> SeqScan on tbl_child_0
> > > -> Hash ... Filter: hash_func(X) % 4 = 0
> > > -> SeqScan on other_table
> > > -> HashJoin
> > > -> SeqScan on tbl_child_1
> > > -> Hash ... Filter: hash_func(X) % 4 = 1
> > > -> SeqScan on other_table
> > > -> HashJoin
> > > -> SeqScan on tbl_child_2
> > > -> Hash ... Filter: hash_func(X) % 4 = 2
> > > -> SeqScan on other_table
> > > -> HashJoin
> > > -> SeqScan on tbl_child_3
> > > -> Hash ... Filter: hash_func(X) % 4 = 3
> > > -> SeqScan on other_table
> > >
> > It may be a good challenge to consider additional join pushdown,
> > even if subpaths of Append are HashJoin, not SeqScan, like:
> >
> > Append
> > -> HashJoin
> > -> HashJoin
> > -> SeqScan on tbl_child_0
> > -> Hash ... Filter: hash_func(X) % 4 = 0
> > -> SeqScan on other_table
> > -> Hash ... Filter: hash_func(X) % 4 = 0
> > -> SeqScan on another_table
> > -> HashJoin
> > -> HashJoin
> > -> SeqScan on tbl_child_1
> > -> Hash ... Filter: hash_func(X) % 4 = 1
> > -> SeqScan on other_table
> > -> Hash ... Filter: hash_func(X) % 4 = 1
> > -> SeqScan on another_table
> > -> HashJoin
> > -> HashJoin
> > -> SeqScan on tbl_child_2
> > -> Hash ... Filter: hash_func(X) % 4 = 2
> > -> SeqScan on other_table
> > -> Hash ... Filter: hash_func(X) % 4 = 2
> > -> SeqScan on another_table
> > -> HashJoin
> > -> HashJoin
> > -> SeqScan on tbl_child_3
> > -> Hash ... Filter: hash_func(X) % 4 = 3
> > -> SeqScan on other_table
> > -> Hash ... Filter: hash_func(X) % 4 = 3
> > -> SeqScan on another_table
> >
> > In this case, underlying nodes are not always SeqScan. So, only
> > Hash-node can have filter clauses.
> >
> >
> > * Way to handle expression nodes
> >
> > All this patch supported is CHECK() constraint with equal operation
> > on INT4
> data
> > type. You can learn various useful infrastructure of PostgreSQL. For example, ...
> > - expression_tree_mutator() is useful to make a copy of expression
> > node with small modification
> > - pull_varnos() is useful to check which relations are referenced
> > by the expression node.
> > - RestrictInfo->can_join is useful to check whether the clause is
> > binary operator, or not.
> >
> >
> > Anyway, reuse of existing infrastructure is the best way to make a
> > reliable infrastructure and to keep the implementation simple.
> >
> > Thanks,
> > --
> > NEC Business Creation Division / PG-Strom Project KaiGai Kohei
> > <kaigai(at)ak(dot)jp(dot)nec(dot)com>
> >
> >
> > > -----Original Message-----
> > > From: pgsql-hackers-owner(at)postgresql(dot)org
> > > [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Taiki
> > > Kondo
> > > Sent: Thursday, August 13, 2015 6:30 PM
> > > To: pgsql-hackers(at)postgresql(dot)org
> > > Cc: Kaigai Kouhei(海外 浩平); Iwaasa Akio(岩浅 晃郎)
> > > Subject: [HACKERS] [Proposal] Table partition + join pushdown
> > >
> > > Hi all,
> > >
> > > I saw the email about the idea from KaiGai-san[1], and I worked to
> > > implement this idea.
> > >
> > > Now, I have implemented a part of this idea, so I want to propose
> > > this feature.
> > >
> > > Patch attached just shows my concept of this feature.
> > > It works fine for EXPLAIN, but it returns wrong result for other
> > > operations,
> > sadly.
> > >
> > >
> > >
> > > Table partition + join pushdown
> > > ===============================
> > >
> > > Motivation
> > > ----------
> > > To make join logic working more effectively, it is important to
> > > make the size of relations smaller.
> > >
> > > Especially in Hash-join, it is meaningful to make the inner
> > > relation smaller, because smaller inner relation can be stored
> > > within smaller hash
> table.
> > > This means that memory usage can be reduced when joining with big tables.
> > >
> > >
> > > Design
> > > ------
> > > It was mentioned by the email from KaiGai-san.
> > > So I quote below here...
> > >
> > > ---- begin quotation ---
> > > Let's assume a table which is partitioned to four portions, and
> > > individual child relations have constraint by hash-value of its ID
> > > field.
> > >
> > > tbl_parent
> > > + tbl_child_0 ... CHECK(hash_func(id) % 4 = 0)
> > > + tbl_child_1 ... CHECK(hash_func(id) % 4 = 1)
> > > + tbl_child_2 ... CHECK(hash_func(id) % 4 = 2)
> > > + tbl_child_3 ... CHECK(hash_func(id) % 4 = 3)
> > >
> > > If someone tried to join another relation with tbl_parent using
> > > equivalence condition, like X = tbl_parent.ID, we know inner
> > > tuples that does not satisfies the condition
> > > hash_func(X) % 4 = 0
> > > shall be never joined to the tuples in tbl_child_0.
> > > So, we can omit to load these tuples to inner hash table
> > > preliminary, then it potentially allows to split the inner hash-table.
> > >
> > > Current typical plan structure is below:
> > >
> > > HashJoin
> > > -> Append
> > > -> SeqScan on tbl_child_0
> > > -> SeqScan on tbl_child_1
> > > -> SeqScan on tbl_child_2
> > > -> SeqScan on tbl_child_3
> > > -> Hash
> > > -> SeqScan on other_table
> > >
> > > It may be rewritable to:
> > >
> > > Append
> > > -> HashJoin
> > > -> SeqScan on tbl_child_0
> > > -> Hash ... Filter: hash_func(X) % 4 = 0
> > > -> SeqScan on other_table
> > > -> HashJoin
> > > -> SeqScan on tbl_child_1
> > > -> Hash ... Filter: hash_func(X) % 4 = 1
> > > -> SeqScan on other_table
> > > -> HashJoin
> > > -> SeqScan on tbl_child_2
> > > -> Hash ... Filter: hash_func(X) % 4 = 2
> > > -> SeqScan on other_table
> > > -> HashJoin
> > > -> SeqScan on tbl_child_3
> > > -> Hash ... Filter: hash_func(X) % 4 = 3
> > > -> SeqScan on other_table
> > > ---- end quotation ---
> > >
> > > In the quotation above, it was written that filter is set at Hash node.
> > > But I implemented that filter is set at SeqScan node under Hash node.
> > > In my opinion, filtering tuples is work of Scanner.
> > >
> > > Append
> > > -> HashJoin
> > > -> SeqScan on tbl_child_0
> > > -> Hash
> > > -> SeqScan on other_table ... Filter: hash_func(X) % 4 = 0
> > > -> HashJoin
> > > -> SeqScan on tbl_child_1
> > > -> Hash
> > > -> SeqScan on other_table ... Filter: hash_func(X) % 4 = 1
> > > -> HashJoin
> > > -> SeqScan on tbl_child_2
> > > -> Hash
> > > -> SeqScan on other_table ... Filter: hash_func(X) % 4 = 2
> > > -> HashJoin
> > > -> SeqScan on tbl_child_3
> > > -> Hash
> > > -> SeqScan on other_table ... Filter: hash_func(X) % 4 = 3
> > >
> > >
> > > API
> > > ---
> > > There are 3 new internal (static) functions to implement this feature.
> > > try_hashjoin_pushdown(), which is main function of this feature,
> > > is called from try_hashjoin_path(), and tries to push down
> > > HashPath under the AppendPath.
> > >
> > > To do so, this function does following operations.
> > >
> > > 1. Check if this Hash-join can be pushed down under AppendPath
> > > 2. To avoid an influence on other Path making operation,
> > > copy inner path's RelOptInfo and make new SeqScan path from it.
> > > At here, get CHECK() constraints from OUTER path, and convert its
> > > Var node according to join condition. And also convert Var nodes
> > > in join condition itself.
> > > 3. Create new HashPath nodes between each sub-paths of AppendPath and
> > > inner path made above.
> > > 4. When operations from 1 to 3 are done for each sub-paths,
> > > create new AppendPath which sub-paths are HashPath nodes made above.
> > >
> > > get_replaced_clause_constr() is called from
> > > try_hashjoin_pushdown(), and get_var_nodes_recurse() is called from get_replaced_cluase_constr().
> > > These 2 functions help above operations.
> > > (I may revise this part to use expression_tree_walker() and
> > > expression_tree_mutator().)
> > >
> > > In patch attached, it has the following limitations.
> > > o It only works for hash-join operation.
> > > (I want to support not only hash-join but also other logic.)
> > > o Join conditions must be "=" operator with int4 variables.
> > > o Inner path must be SeqScan.
> > > (I want to support other path-node.)
> > > o And now, planner may not choose this plan,
> > > because estimated costs are usually larger than original
> > > (non-pushdown)
> > plan.
> > >
> > > And also 1 internal (static) function, get_relation_constraints()
> > > defined in plancat.c, is changed to global. This function will be
> > > called from
> > > get_replaced_clause_constr() to get CHECK() constraints.
> > >
> > >
> > > Usage
> > > -----
> > > To use this feature, create partition tables and small table to
> > > join, and run select operation with joining these tables.
> > >
> > > For your convenience, I attach DDL and DML script.
> > > And I also attach the result of EXPLAIN.
> > >
> > >
> > > Any comments are welcome. But, at first, I need your advices to
> > > correct this patch's behavior.
> > >
> > > At least, I think it has to expand array of RangeTblEntry and
> > > other arrays defined in PlannerInfo to register new RelOptInfos
> > > for new Path nodes
> > mentioned above.
> > > Or, is it better choice to modify query parser to implement this
> > > feature more further?
> > >
> > >
> > > Remarks :
> > > [1]
> > > http://www.postgresql.org/message-id/9A28C8860F777E439AA12E8AEA769
> > > 4F80
> > > 10F672
> > > B(at)BPXM15GP(dot)gisp(dot)nec(dot)co(dot)jp
> > >
> > >
> > > Best regards,
> > > --
> > > Taiki Kondo
> > >
> > > NEC Solution Innovators, Ltd.
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org) To
> make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org) To
> make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>