Re: Custom Scan APIs (Re: Custom Plan node)

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

In response to

Browse pgsql-hackers by date

  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