(2014/01/28 22:01), Etsuro Fujita wrote:
(2014/01/27 21:49), Shigeru Hanada wrote:
Is it too big change that making ANALYZE command to handle foreign
tables too even if no table name was specified? IIRC, performance
issue was the reason to exclude foreign tables from auto-analyze
processing.
(2014/01/27 21:49), Shigeru Hanada wrote:
2014-01-27 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/01/25 11:27), Shigeru Hanada wrote:
Yeah, the consistency is essential for its ease of use. But I'm not sure
that inherited stats ignoring foreign tables is actually useful for query
2014-01-27 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/01/25 11:27), Shigeru Hanada wrote:
Yeah, the consistency is essential for its ease of use. But I'm not sure
that inherited stats ignoring foreign tables is actually useful for query
optimization. What I think about the consistency
(2014/01/25 11:27), Shigeru Hanada wrote:
2014/1/23 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
Shigeru Hanada wrote:
Though this would be debatable, in current implementation, constraints
defined on a foreign table (now only NOT NULL and CHECK are supported)
are not enforced during INSERT or
Hi Fujita-san,
Thanks for the review.
2014/1/23 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
Shigeru Hanada wrote:
Though this would be debatable, in current implementation, constraints
defined on a foreign table (now only NOT NULL and CHECK are supported)
are not enforced during INSERT or
Shigeru Hanada wrote:
Attached patch allows a foreign table to be a child of a table. It
also allows foreign tables to have CHECK constraints.
Sorry for the delay. I started to look at this patch.
Though this would be debatable, in current implementation, constraints
defined on a foreign
