Re: Custom Scan APIs (Re: Custom Plan node) - Mailing list pgsql-hackers

From Shigeru Hanada
Subject Re: Custom Scan APIs (Re: Custom Plan node)
Date
Msg-id CAEZqfEdzrf=MG5XjbA3iBWg+SPNm5XignrqLbR_nEHqv4NV_XA@mail.gmail.com
Whole thread Raw
In response to Re: Custom Scan APIs (Re: Custom Plan node)  (Kouhei Kaigai <kaigai@ak.jp.nec.com>)
List pgsql-hackers
Hi Kaigai-san,

2014-02-25 13:28 GMT+09:00 Kouhei Kaigai <kaigai@ak.jp.nec.com>:
> The reason why I asked the question above is, I haven't been 100% certain
> about its usage. Indeed, semifactors is applied on a limited usage, but
> quite easy to reproduce by extension later (using clauselist_selectivity)
> if extension wants this factor. So, I agree with removing the semifactors
> here.

Agreed.  It would be nice to mention how to obtain semifactos for
people who want to implement advanced join overriding.

>> mergeclause_list and param_source_rels seem little easier to use, but
>> anyway it should be documented how to use those parameters.
>>
> The mergeclause_list might not be sufficient for extensions to determine
> whether its own mergejoin is applicable here. See the comment below; that
> is on the head of select_mergejoin_clauses.
>
> |  * *mergejoin_allowed is normally set to TRUE, but it is set to FALSE if
> |  * this is a right/full join and there are nonmergejoinable join clauses.
> |  * The executor's mergejoin machinery cannot handle such cases, so we have
> |  * to avoid generating a mergejoin plan.  (Note that this flag does NOT
> |  * consider whether there are actually any mergejoinable clauses.  This is
> |  * correct because in some cases we need to build a clauseless mergejoin.
> |  * Simply returning NIL is therefore not enough to distinguish safe from
> |  * unsafe cases.)
> |
> It says, mergejoin_clause == NIL is not a sufficient check to determine
> whether the mergejoin logic is applicable on the target join.
> So, either of them is probably an option for extension that tries to implement

Perhaps you mean "both of them"?

> their own mergejoin logic; (1) putting both of mergejoin_allowed and
> mergeclause_list as arguments of the hook, or (2) re-definition of
> select_mergejoin_clauses() as extern function to reproduce the variables on
> demand. Which one is more preferable?

I prefer (1), because exposing inside of planner might blocks changing
those internal functions.  If (at the moment) those information is
enough for overriding merge join for CSP, let's provide as parameters.


-- 
Shigeru HANADA



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: In which good intentions are punished, take 2
Next
From: Andrew Dunstan
Date:
Subject: Re: In which good intentions are punished, take 2