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 CAEZqfEd5kodSzZ9TEFM3W3Qn2xKVrrNgriONkQLNNyQb3Em0fw@mail.gmail.com
Whole thread Raw
In response to Re: Custom Scan APIs (Re: Custom Plan node)  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: Custom Scan APIs (Re: Custom Plan node)
List pgsql-hackers
Hi KaiGai-san,

2013/12/8 Kohei KaiGai <kaigai@kaigai.gr.jp>:
> The attached patches include documentation fixup by Hanada-san,
> and relocation of is_managed_relation (the portion to check whether
> the relation is a foreign table managed by a particular FDW) and
> has_wholerow_reference.
> I didn't touch the EXPLAIN logic because I'm uncertain whether the
> cost of remote join is reasonable towards the cost as an alternative
> path to local joins.
>
> Please check it. Thanks,

The patches could be applied cleanly, but I saw a compiler warning
about get_rel_relkind() in foreign.c, but it's minor issue.  Please
just add #include of utils/lsyscache.h there.

I have some more random comments about EXPLAIN.

1) You use "Operation" as the label of Custom Scan nodes in non-text
format, but it seems to me rather "provider name".  What is the string
shown there?

2) It would be nice if we can see the information about what the
Custom Scan node replaced in EXPLAIN output (even only in verbose
mode).  I know that we can't show plan tree below custom scan nodes,
because CS Provider can't obtain other candidates.  But even only
relation names used in the join or the scan would help users to
understand what is going on in Custom Scan.

Regards,
-- 
Shigeru HANADA



pgsql-hackers by date:

Previous
From: Albe Laurenz
Date:
Subject: Re: ANALYZE sampling is too good
Next
From: Peter Geoghegan
Date:
Subject: pg_stat_statements fingerprinting logic and ArrayExpr