From: | Abbas Butt <abbas(dot)butt(at)enterprisedb(dot)com> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: An issue in remote query optimization |
Date: | 2017-01-31 10:53:34 |
Message-ID: | CALtH27eoFU3oKNEgRvHXZktz7PxxEckVKfJ417Ti9xiKywA8xA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 31, 2017 at 2:25 AM, Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
wrote:
> On 2017/01/31 18:24, Abbas Butt wrote:
>
>> Postgres_fdw optimizes remote queries by pushing down the where clause.
>> This feature does not work consistently when the query is executed from
>> within a pl/pgsql function. The optimization works when the function
>> 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 it
>> 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
>> down.
>>
>> How should we fix this problem?
>>
>
> ANALYZE for the foreign table doesn't work?
>
No.
analyze ts.tickets;
WARNING: skipping "tickets" --- cannot analyze this foreign table
ANALYZE
>
> Best regards,
> Etsuro Fujita
>
>
>
--
--
*Abbas*
Architect
Ph: 92.334.5100153
Skype ID: gabbasb
www.enterprisedb.co <http://www.enterprisedb.com/>m
<http://www.enterprisedb.com/>
*Follow us on Twitter*
@EnterpriseDB
Visit EnterpriseDB for tutorials, webinars, whitepapers
<http://www.enterprisedb.com/resources-community> and more
<http://www.enterprisedb.com/resources-community>
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2017-01-31 11:01:11 | Re: parallelize queries containing subplans |
Previous Message | Amit Kapila | 2017-01-31 10:46:59 | Re: parallelize queries containing initplans |