Re: [HACKERS] An issue in remote query optimization - Mailing list pgsql-hackers

From Abbas Butt
Subject Re: [HACKERS] An issue in remote query optimization
Date
Msg-id CALtH27eoFU3oKNEgRvHXZktz7PxxEckVKfJ417Ti9xiKywA8xA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] An issue in remote query optimization  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: [HACKERS] An issue in remote query optimization  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
List pgsql-hackers


On Tue, Jan 31, 2017 at 2:25 AM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.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
Skype ID: gabbasb
www.enterprisedb.com

Follow us on Twitter

@EnterpriseDB

Visit EnterpriseDB for tutorials, webinars, whitepapers and more

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] parallelize queries containing initplans
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] parallelize queries containing subplans