From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Abbas Butt <abbas(dot)butt(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: An issue in remote query optimization |
Date: | 2017-01-31 11:15:28 |
Message-ID: | 5d8db7bc-7d4a-8522-7905-9c3a8330849d@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017/01/31 19:53, Abbas Butt wrote:
> On Tue, Jan 31, 2017 at 2:25 AM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp <mailto: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
How the foreign table ts.tickets is defined?
Best regards,
Etsuro Fujita
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2017-01-31 11:22:39 | Re: Patch: Write Amplification Reduction Method (WARM) |
Previous Message | Dilip Kumar | 2017-01-31 11:05:57 | Re: Parallel bitmap heap scan |