Workaround:
The workaround is to rewrite the query, cast the 2nd Parameter from date to other formats like timestamp.
set optimizer_trace_fallback = 1;
EXPLAIN SELECT * FROM ( SELECT date_part('year'::text, 'now'::text::timestamp) ) sub ;
QUERY PLAN
------------------------------------------------
Result (cost=0.00..0.00 rows=1 width=8)
-> Result (cost=0.00..0.00 rows=1 width=1)
Optimizer: Pivotal Optimizer (GPORCA)
(3 rows)
The reason behind this is that the date_part function can accept different inputs and each kind of function refers to a different code. Some are SQL defined functions while others are compiled source code.
Calling the functions which are defined as SQL will triggered the fall back to Planner.
Calling the functions which are defained as C functions will all Pivotal Optimizer (GPORCA) to create a plan.
To check which functions are C functions (highlighed below), list the funotions with "\df+ date_part":
iadpprod=# \df+ date_part
List of functions
Schema | Name |... | Argument data types |...| Source code |......
------------+-----------+...-+-----------------------------------+...+--------------------------------------------------------------------------+......
pg_catalog | date_part |... | text, abstime |...| select pg_catalog.date_part($1, cast($2 as timestamp with time zone)) |......
pg_catalog | date_part |... | text, date |...| select pg_catalog.date_part($1, cast($2 as timestamp without time zone)) |......
pg_catalog | date_part |... | text, interval |...| interval_part |......
pg_catalog | date_part |... | text, reltime |...| select pg_catalog.date_part($1, cast($2 as pg_catalog.interval)) |......
pg_catalog | date_part |... | text, timestamp without time zone |...| timestamp_part |......
pg_catalog | date_part |... | text, timestamp with time zone |...| timestamptz_part |......
pg_catalog | date_part |... | text, time without time zone |...| time_part |......
pg_catalog | date_part |... | text, time with time zone |...| timetz_part |......