Re: Ideas about a better API for postgres_fdw remote estimates

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Ideas about a better API for postgres_fdw remote estimates
Дата
Msg-id CAG-ACPWRAao++Fc+A_P7-+Z5d7d4ze72DiRvbNr7Rw29iPRcUQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Ideas about a better API for postgres_fdw remote estimates  ("Andrey V. Lepikhov" <a.lepikhov@postgrespro.ru>)
Ответы Re: Ideas about a better API for postgres_fdw remote estimates
Список pgsql-hackers


On Thu, 3 Sep 2020 at 10:44, Andrey V. Lepikhov <a.lepikhov@postgrespro.ru> wrote:
On 8/31/20 6:19 PM, Ashutosh Bapat wrote:
> On Mon, Aug 31, 2020 at 3:36 PM Andrey V. Lepikhov
> <a.lepikhov@postgrespro.ru> wrote:
>>
>> Thanks for this helpful feedback.
> I think the patch has some other problems like it works only for
> regular tables on foreign server but a foreign table can be pointing
> to any relation like a materialized view, partitioned table or a
> foreign table on the foreign server all of which have statistics
> associated with them. I didn't look closely but it does not consider
> that the foreign table may not have all the columns from the relation
> on the foreign server or may have different names. But I think those
> problems are kind of secondary. We have to agree on the design first.
>
In accordance with discussion i made some changes in the patch:
1. The extract statistic routine moved into the core.

Bulk of the patch implements the statistics conversion to and fro json format. I am still not sure whether we need all of that code here. Can we re-use pg_stats view? That is converting some of the OIDs to names. I agree with anyarray but if that's a problem here it's also a problem for pg_stats view, isn't it? If we can reduce the stats handling code to a minimum or use it for some other purpose as well e.g. pg_stats enhancement, the code changes required will be far less compared to the value that this patch provides.

--
Best Wishes,
Ashutosh

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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Disk-based hash aggregate's cost model
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Rare deadlock failure in create_am test