Re: [HACKERS] An issue in remote query optimization

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: [HACKERS] An issue in remote query optimization
Дата
Msg-id 5d8db7bc-7d4a-8522-7905-9c3a8330849d@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [HACKERS] An issue in remote query optimization  (Abbas Butt <abbas.butt@enterprisedb.com>)
Ответы Re: [HACKERS] An issue in remote query optimization  (Abbas Butt <abbas.butt@enterprisedb.com>)
Список pgsql-hackers
On 2017/01/31 19:53, Abbas Butt wrote:
> On Tue, Jan 31, 2017 at 2:25 AM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp <mailto: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

How the foreign table ts.tickets is defined?

Best regards,
Etsuro Fujita





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: [HACKERS] Parallel bitmap heap scan
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)