Thread: postgres_fdw - IS TRUE/FALSE conditions are not pushed down
Hi
I've setup foreign table and noticed inconsistency how conditionals handled for boolean columns.
explain verbose select * from temporary_testing.t_proxied where active is true;
QUERY PLAN
--------------------------------------------------------------------------------------
Foreign Scan on temporary_testing.t_proxied (cost=100.00..194.72 rows=1412 width=5)
Output: id, active
Filter: (t_proxied.active IS TRUE)
Remote SQL: SELECT id, active FROM main_testing.t_url
But, when = used instead of IS it works correctly. All conditions below (including IS NULL) are pushed down to remote server:
explain verbose select * from temporary_testing.t_proxied where active;
explain verbose select * from temporary_testing.t_proxied where NOT(active);
explain verbose select * from temporary_testing.t_proxied where active = false;
explain verbose select * from temporary_testing.t_proxied where active = true;
--------------------------------------------------------------------------------------
Foreign Scan on temporary_testing.t_proxied (cost=100.00..166.48 rows=1412 width=5)
Output: id, active
Remote SQL: SELECT id, active FROM main_testing.t_url WHERE (active)
explain verbose select * from temporary_testing.t_proxied where active is null;
QUERY PLAN
------------------------------------------------------------------------------------
Foreign Scan on temporary_testing.t_proxied (cost=100.00..138.52 rows=14 width=5)
Output: id, active
Remote SQL: SELECT id, active FROM main_testing.t_url WHERE ((active IS NULL))
DO I need to report this as bug?
Tested on PostgreSQL 9.3.4
I've setup foreign table and noticed inconsistency how conditionals handled for boolean columns.
explain verbose select * from temporary_testing.t_proxied where active is true;
QUERY PLAN
--------------------------------------------------------------------------------------
Foreign Scan on temporary_testing.t_proxied (cost=100.00..194.72 rows=1412 width=5)
Output: id, active
Filter: (t_proxied.active IS TRUE)
Remote SQL: SELECT id, active FROM main_testing.t_url
But, when = used instead of IS it works correctly. All conditions below (including IS NULL) are pushed down to remote server:
explain verbose select * from temporary_testing.t_proxied where active;
explain verbose select * from temporary_testing.t_proxied where NOT(active);
explain verbose select * from temporary_testing.t_proxied where active = false;
explain verbose select * from temporary_testing.t_proxied where active = true;
--------------------------------------------------------------------------------------
Foreign Scan on temporary_testing.t_proxied (cost=100.00..166.48 rows=1412 width=5)
Output: id, active
Remote SQL: SELECT id, active FROM main_testing.t_url WHERE (active)
explain verbose select * from temporary_testing.t_proxied where active is null;
QUERY PLAN
------------------------------------------------------------------------------------
Foreign Scan on temporary_testing.t_proxied (cost=100.00..138.52 rows=14 width=5)
Output: id, active
Remote SQL: SELECT id, active FROM main_testing.t_url WHERE ((active IS NULL))
DO I need to report this as bug?
Tested on PostgreSQL 9.3.4
--
Sergiy Zuban
Sergiy Zuban
Sergiy Zuban <s.zuban@gmail.com> writes:
> DO I need to report this as bug?
It's not a bug, but an unimplemented feature. A patch submission would be
more likely to get you somewhere. Look into contrib/postgres_fdw/deparse.c,
and add support for BooleanTest (the NullTest support is a good model).
regards, tom lane