From: | Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com> |
---|---|
To: | Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, Stephen Frost <sfrost(at)snowman(dot)net>, Jim Mlodgenski <jimmy76(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PgHacker <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net> |
Subject: | Re: Custom Scan APIs (Re: Custom Plan node) |
Date: | 2014-02-26 02:29:16 |
Message-ID: | CAEZqfEdzrf=MG5XjbA3iBWg+SPNm5XignrqLbR_nEHqv4NV_XA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Kaigai-san,
2014-02-25 13:28 GMT+09:00 Kouhei Kaigai <kaigai(at)ak(dot)jp(dot)nec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-02-26 02:43:09 | Re: In which good intentions are punished, take 2 |
Previous Message | Alvaro Herrera | 2014-02-26 01:53:07 | Re: In which good intentions are punished, take 2 |