On Tue, Sep 8, 2015 at 5:35 AM, Etsuro Fujita
wrote:
> On 2015/09/04 0:33, Robert Haas wrote:
>> I'm worried that trawling through that
>> SpecialJoinInfo data will end up needing to duplicate much of
>> make_join_rel and add_paths_to_joinrel. For example, consider:
>>
>> SELECT * FROM verysmall
On 2015/09/04 0:33, Robert Haas wrote:
I'm worried that trawling through that
SpecialJoinInfo data will end up needing to duplicate much of
make_join_rel and add_paths_to_joinrel. For example, consider:
SELECT * FROM verysmall v JOIN (bigft1 FULL JOIN bigft2 ON bigft1.x =
bigft2.x) ON v.q = big
On 2015/09/02 23:30, Tom Lane wrote:
> Etsuro Fujita writes:
>> On 2015/08/01 23:25, Tom Lane wrote:
>>> In my vision you probably really only want one call per build_join_rel
>>> event (that is, per construction of a new RelOptInfo), not per
>>> make_join_rel event.
>> I'd vote for hooking at st
Hello, sorry in advance for possible brought up of past
discussions or pointless discussion.
> I'm attaching an updated version of the patch. The patch is based on
> the SS_finalize_plan patch that has been recently committed. I'd be
> happy if this helps people discuss more about how to fix thi
On 2015/09/04 19:50, Etsuro Fujita wrote:
I'm attaching an updated version of the patch. The patch is based on
the SS_finalize_plan patch that has been recently committed. I'd be
happy if this helps people discuss more about how to fix this issue.
In the updated version, I modified finalize_p
On 2015/09/03 19:25, Etsuro Fujita wrote:
On 2015/09/03 14:22, Etsuro Fujita wrote:
On 2015/09/03 9:41, Robert Haas wrote:
That having been said, I don't entirely like Fujita-san's patch
either. Much of the new code is called immediately adjacent to an FDW
callback which could pretty trivially
Robert Haas writes:
> On Wed, Sep 2, 2015 at 1:47 PM, Tom Lane wrote:
>> Offhand I think that the
>> most likely way to build that text will be to examine the query's jointree
>> to see where c,d,e appear in it. But in any case, that's a separate issue
>> and I fail to see how plopping the join
On Wed, Sep 2, 2015 at 1:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 2, 2015 at 10:30 AM, Tom Lane wrote:
>>> But if you have in mind that typical FDWs would actually create join paths
>>> at that point, consider that
>>>
>>> 1. The FDW would have to find all the combinations of
> , On Wed, Aug 26, 2015 at 4:05 AM, Kouhei Kaigai wrote:
> >> On 2015/08/26 16:07, Kouhei Kaigai wrote:
> >> I wrote:
> >> >> Maybe I'm missing something, but why do we need such a flexiblity for
> >> >> the columnar-stores?
> >>
> >> > Even if we enforce them a new interface specification comfor
On 2015/09/03 14:22, Etsuro Fujita wrote:
On 2015/09/03 9:41, Robert Haas wrote:
That having been said, I don't entirely like Fujita-san's patch
either. Much of the new code is called immediately adjacent to an FDW
callback which could pretty trivially do the same thing itself, if
needed.
An
On 2015/09/03 9:41, Robert Haas wrote:
That having been said, I don't entirely like Fujita-san's patch
either. Much of the new code is called immediately adjacent to an FDW
callback which could pretty trivially do the same thing itself, if
needed.
Another idea about that code is to call that c
, On Wed, Aug 26, 2015 at 4:05 AM, Kouhei Kaigai wrote:
>> On 2015/08/26 16:07, Kouhei Kaigai wrote:
>> I wrote:
>> >> Maybe I'm missing something, but why do we need such a flexiblity for
>> >> the columnar-stores?
>>
>> > Even if we enforce them a new interface specification comfortable to RDBMS
I wrote:
> ... I imagine that we should allow FDWs to
> store some data within RelOptInfo structs that represent foreign joins
> belonging entirely to them, so that there'd be a handy place to keep that
> data till later.
Actually, if we do that (ie, provide a "void *fdw_state" field in join
RelOp
Robert Haas writes:
> On Wed, Sep 2, 2015 at 10:30 AM, Tom Lane wrote:
>> But if you have in mind that typical FDWs would actually create join paths
>> at that point, consider that
>>
>> 1. The FDW would have to find all the combinations of its supplied
>> relations (unless you are only intendin
On Wed, Sep 2, 2015 at 10:30 AM, Tom Lane wrote:
> But if you have in mind that typical FDWs would actually create join paths
> at that point, consider that
>
> 1. The FDW would have to find all the combinations of its supplied
> relations (unless you are only intending to generate one path for th
Etsuro Fujita writes:
> On 2015/08/01 23:25, Tom Lane wrote:
>> In my vision you probably really only want one call per build_join_rel
>> event (that is, per construction of a new RelOptInfo), not per
>> make_join_rel event.
> I'd vote for hooking at standard_join_search.
I think that method wou
On 2015/08/01 23:25, Tom Lane wrote:
> Robert Haas writes:
>> The problem that was bothering us (or at least what was bothering me)
>> is that the PlannerInfo provides only a list of SpecialJoinInfo
>> structures, which don't directly give you the original join order. In
>> fact, min_righthand an
On 2015/08/27 17:30, Etsuro Fujita wrote:
I think we would probably need others' opinions about this issue.
Attached is an updated version of the patch [1]. I'd be happy if it
helps people discuss about this issue.
Changes:
* rebased to HEAD.
* add some more docs and comments.
* fix a bug i
On 2015/08/27 16:52, Kouhei Kaigai wrote:
I wrote:
I don't understand what you proposed,
What I'm talking about is philosophy of software/interface design.
I understand EPQ recheck by alternative plan is "one" reasonable way,
however, people often have different ideas and may be better than
yo
> > As I have said repeatedly, it is software design decision by the author
> > of extension. Even if it consumes 100 times larger memory and 1000 times
> > slower, it is his decision and responsibility.
> > Why he has to be forced to use a particular logic despite his intension?
>
> I don't under
On 2015/08/27 11:08, Kouhei Kaigai wrote:
On 2015/08/26 18:01, Kouhei Kaigai wrote:
You may think execution of alternative plan is the best way for EPQ rechecks,
however, other folks may think their own implementation is the best for EPQ
rechecks. I never argue which approach is better.
What I p
> On 2015/08/26 18:01, Kouhei Kaigai wrote:
> >>> You may think execution of alternative plan is the best way for EPQ
> >>> rechecks,
> >>> however, other folks may think their own implementation is the best for
> >>> EPQ
> >>> rechecks. I never argue which approach is better.
> >>> What I point
On 2015/08/26 18:01, Kouhei Kaigai wrote:
You may think execution of alternative plan is the best way for EPQ rechecks,
however, other folks may think their own implementation is the best for EPQ
rechecks. I never argue which approach is better.
What I point out is freedom/flexibility of implemen
> -Original Message-
> From: Etsuro Fujita [mailto:fujita.ets...@lab.ntt.co.jp]
> Sent: Wednesday, August 26, 2015 5:38 PM
> To: Kaigai Kouhei(海外 浩平); Robert Haas
> Cc: PostgreSQL-development; 花田茂
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
On 2015/08/26 17:05, Kouhei Kaigai wrote:
On 2015/08/26 16:07, Kouhei Kaigai wrote:
Even if we enforce them a new interface specification comfortable to RDBMS,
we cannot guarantee it is also comfortable to other type of FDW drivers.
Specifically, what kind of points about the patch are specif
> On 2015/08/26 16:07, Kouhei Kaigai wrote:
> I wrote:
> >> Maybe I'm missing something, but why do we need such a flexiblity for
> >> the columnar-stores?
>
> > Even if we enforce them a new interface specification comfortable to RDBMS,
> > we cannot guarantee it is also comfortable to other type
On 2015/08/26 16:07, Kouhei Kaigai wrote:
I wrote:
Maybe I'm missing something, but why do we need such a flexiblity for
the columnar-stores?
Even if we enforce them a new interface specification comfortable to RDBMS,
we cannot guarantee it is also comfortable to other type of FDW drivers.
S
> > In addition, you may misunderstand the proposition of mine above.
> > You can check RelOptInfo->fdw_private on top of the GetForeignJoinPaths,
> > then, if it is second or later invocation, you can check cost of the
> > alternative path kept in the ForeignPath node previously constructed.
> > I
On 2015/08/26 13:49, Kouhei Kaigai wrote:
On 2015/08/25 10:18, Kouhei Kaigai wrote:
Likely, what you need to do are...
1. Save the alternative path on fdw_paths when foreign join push-down.
GetForeignJoinPaths() may be called multiple times towards a particular
joinrel according to the
> On 2015/08/25 10:18, Kouhei Kaigai wrote:
> > How about your opinion towards the solution?
>
> >> Likely, what you need to do are...
> >> 1. Save the alternative path on fdw_paths when foreign join push-down.
> >> GetForeignJoinPaths() may be called multiple times towards a particular
> >>
Hi KaiGai-san,
On 2015/08/25 10:18, Kouhei Kaigai wrote:
How about your opinion towards the solution?
Likely, what you need to do are...
1. Save the alternative path on fdw_paths when foreign join push-down.
GetForeignJoinPaths() may be called multiple times towards a particular
joinr
tgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kouhei Kaigai
> Sent: Thursday, August 13, 2015 10:13 AM
> To: Etsuro Fujita; Robert Haas
> Cc: PostgreSQL-development; 花田茂
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> Fujita-san,
>
平)
> Sent: Wednesday, August 12, 2015 11:17 PM
> To: 'Etsuro Fujita'; Robert Haas
> Cc: PostgreSQL-development; 花田茂
> Subject: RE: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> > -Original Message-
> > From: pgsql-hackers-ow...@postgresql.org
> >
Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> On 2015/08/12 7:21, Robert Haas wrote:
> > On Fri, Aug 7, 2015 at 3:37 AM, Kouhei Kaigai wrote:
> >>> I could have a discussion with Fujita-san about this topic.
> >>>
> >> Also, let me share with the
On 2015/08/12 7:21, Robert Haas wrote:
On Fri, Aug 7, 2015 at 3:37 AM, Kouhei Kaigai wrote:
I could have a discussion with Fujita-san about this topic.
Also, let me share with the discussion towards entire solution.
The primitive reason of this problem is, Scan node with scanrelid==0
represe
On Fri, Aug 7, 2015 at 3:37 AM, Kouhei Kaigai wrote:
>> I could have a discussion with Fujita-san about this topic.
>>
> Also, let me share with the discussion towards entire solution.
>
> The primitive reason of this problem is, Scan node with scanrelid==0
> represents a relation join that can in
gt; Sent: Saturday, August 01, 2015 10:35 PM
> To: Robert Haas; Etsuro Fujita
> Cc: PostgreSQL-development; 花田茂
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> > On Fri, Jul 3, 2015 at 6:25 AM, Etsuro Fujita
> > wrote:
> > > Can't FDWs g
Robert Haas writes:
> The problem that was bothering us (or at least what was bothering me)
> is that the PlannerInfo provides only a list of SpecialJoinInfo
> structures, which don't directly give you the original join order. In
> fact, min_righthand and min_lefthand are intended to constraint t
> On Fri, Jul 3, 2015 at 6:25 AM, Etsuro Fujita
> wrote:
> > Can't FDWs get the join information through the root, which I think we would
> > pass to the API as the argument?
>
> This is exactly what Tom suggested originally, and it has some appeal,
> but neither KaiGai nor I could see how to mak
On Fri, Jul 3, 2015 at 6:25 AM, Etsuro Fujita
wrote:
> Can't FDWs get the join information through the root, which I think we would
> pass to the API as the argument?
This is exactly what Tom suggested originally, and it has some appeal,
but neither KaiGai nor I could see how to make it work . D
On 2015/07/07 19:15, Etsuro Fujita wrote:
On 2015/07/06 9:42, Kouhei Kaigai wrote:
However, we need to pay attention on advantages towards the alternatives.
Hooks on add_paths_to_joinrel() enables to implement identical stuff,
with
less complicated logic to reproduce left / right relations from
On 2015/07/06 9:42, Kouhei Kaigai wrote:
Also, I don't want to stick on the assumption that relations involved in
remote join are all managed by same foreign-server no longer.
The following two ideas introduce possible enhancement of remote join
feature that involved local relations; replicated t
> > Also, I don't want to stick on the assumption that relations involved in
> > remote join are all managed by same foreign-server no longer.
> > The following two ideas introduce possible enhancement of remote join
> > feature that involved local relations; replicated table or transformed
> > to
On 2015/07/03 15:32, Kouhei Kaigai wrote:
On 2015/07/02 23:13, Kouhei Kaigai wrote:
To be honest, ISTM that it's difficult to do that simply and efficiently
for the foreign/custom-join-pushdown API that we have for 9.5. It's a
little late, but what I started thinking is to redesign that API so
> On 2015/07/02 23:13, Kouhei Kaigai wrote:
> >> To be honest, ISTM that it's difficult to do that simply and efficiently
> >> for the foreign/custom-join-pushdown API that we have for 9.5. It's a
> >> little late, but what I started thinking is to redesign that API so that
> >> that API is called
On 2015/07/02 23:13, Kouhei Kaigai wrote:
To be honest, ISTM that it's difficult to do that simply and efficiently
for the foreign/custom-join-pushdown API that we have for 9.5. It's a
little late, but what I started thinking is to redesign that API so that
that API is called at standard_join_se
> > Let me introduce a few cases we should pay attention.
> >
> > Foreign/CustomScan node may stack; that means a Foreign/CustomScan node
> > may have child node that includes another Foreign/CustomScan node with
> > scanrelid==0.
> > (At this moment, ForeignScan cannot have child node, however, mo
Hi KaiGai-san,
On 2015/07/02 18:31, Kouhei Kaigai wrote:
Even though I'd like to see committer's opinion, I could not come up
with the idea better than what you proposed; foreign-/custom-scan
has alternative plan if scanrelid==0.
I'd also like to hear the opinion!
Let me introduce a few case
Hi Fujita-san,
Sorry for my late.
> On 2015/06/27 21:09, Kouhei Kaigai wrote:
> >>> BTW, if you try newer version of postgres_fdw foreign join patch,
> >>> please provide me to reproduce the problem/
>
> >> OK
>
> > Did you forget to attach the patch, or v17 is in use?
>
> Sorry, I made a mist
Hi KaiGai-san,
On 2015/06/27 21:09, Kouhei Kaigai wrote:
BTW, if you try newer version of postgres_fdw foreign join patch,
please provide me to reproduce the problem/
OK
Did you forget to attach the patch, or v17 is in use?
Sorry, I made a mistake. The problem was produced using v16 [1]
hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Etsuro Fujita
> Sent: Thursday, June 25, 2015 3:12 PM
> To: Kaigai Kouhei(海外 浩平)
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPlanQual
>
> Hi KaiGa
Hi KaiGai-san,
I'd like to work on this issue with you!
On 2015/06/25 10:48, Kouhei Kaigai wrote:
I'd like to suggest a solution that re-construct remote tuple according
to the fdw_scan_tlist on ExecScanFetch, if given scanrelid == 0.
It enables to run local qualifier associated with the Foreig
nal Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kohei KaiGai
> Sent: Wednesday, June 24, 2015 10:02 PM
> To: Etsuro Fujita
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Foreign join pushdown vs EvalPl
Does it make sense to put the result tuple of remote join on evety
estate->es_epqTupleSet[] slot represented by this ForeignScan if
scanrelid==0?
It allows to recheck qualifier for each LockRow that intends to lock
base foreign table underlying the remote join.
ForeignScan->fdw_relids tells us whi
201 - 254 of 254 matches
Mail list logo
