On Tue, Jan 31, 2017 at 3:15 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp>
> On 2017/01/31 19:53, Abbas Butt wrote:
>> On Tue, Jan 31, 2017 at 2:25 AM, Etsuro Fujita
>> <fujita.ets...@lab.ntt.co.jp <mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>> On 2017/01/31 18:24, Abbas Butt wrote:
> Postgres_fdw optimizes remote queries by pushing down the where
>> This feature does not work consistently when the query is
>> executed from
>> within a pl/pgsql function. The optimization works when the
>> executes the query for the first 5 times, and fails afterwards.
> I understand that this is because PostgreSQL starts using
>> generic plan
>> with pulled up where clause after the 5th invocation hoping that
>> would be faster since we have skiped planning the query on each
>> invocation, but in this case this decision is causing the query
>> to slow
> How should we fix this problem?
> ANALYZE for the foreign table doesn't work?
>> analyze ts.tickets;
>> WARNING: skipping "tickets" --- cannot analyze this foreign table
> How the foreign table ts.tickets is defined?
test=# \d ts.tickets
Foreign table "ts.tickets"
Column | Type | Modifiers | FDW Options
id | integer | not null |
FDW Options: (dbname 'msql_test_db', table_name 'tickets')
Its a foreign table, referring to table 'tickets' defined on MySQL.
> Best regards,
> Etsuro Fujita
Skype ID: gabbasb
*Follow us on Twitter*
Visit EnterpriseDB for tutorials, webinars, whitepapers
<http://www.enterprisedb.com/resources-community> and more