On Sun, Nov 23, 2025 at 4:28 PM Corey Huinker wrote:
> I've reorganized some things a bit, mostly to make resource cleanup simpler.
Thanks for updating the patch! I will look into it.
Best regards,
Etsuro Fujita
On Sat, Nov 22, 2025 at 6:31 AM Corey Huinker wrote:
>> Other initial comments:
>>
>> The commit message says:
>>
>> This is managed via two new options, fetch_stats and remote_analyze,
>> both are available at the server level and table level. If fetch_stats
>> is true, then the ANALY
> On Nov 23, 2025, at 15:27, Corey Huinker wrote:
>
> My apologies for the delayed response.
>
> Valuable responses are worth waiting for.
>
> I've reorganized some things a bit, mostly to make resource cleanup simpler.
>
Few comments:
1 - commit message
```
effort and the user is bet
>
>
>
>> My apologies for the delayed response.
>>
>
> Valuable responses are worth waiting for.
>
I've reorganized some things a bit, mostly to make resource cleanup
simpler.
From c387c379f4a8ba83073fd3e8d697368fe3250aa4 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Thu, 7 Aug 2025 23:58:38
>
> Other initial comments:
>
> The commit message says:
>
> This is managed via two new options, fetch_stats and remote_analyze,
> both are available at the server level and table level. If fetch_stats
> is true, then the ANALYZE command will first attempt to fetch
> statistics
> f
Hi Corey,
This is an important feature. Thanks for working on it.
On Mon, Nov 3, 2025 at 2:26 PM Corey Huinker wrote:
>> My point is: rather than trying to implement a second solution with a
>> new callback, shouldn't we try to rework the existing callback so as
>> it would fit better with wha
>
> I am a bit uncomfortable regarding the design you are using here,
> where the ImportStatistics callback, if defined, takes priority over
> the existing AnalyzeForeignTable, especially regarding the fact that
> both callbacks attempt to retrieve the same data, except that the
> existing callback
On Mon, Oct 20, 2025 at 03:45:14PM +0900, Michael Paquier wrote:
> On Sat, Oct 18, 2025 at 08:32:24PM -0400, Corey Huinker wrote:
> > Rebased again.
>
> Hearing an opinion from Fujita-san would be interesting here, so I am
> adding him in CC. I have been looking a little bit at this patch.
By th
On Sat, Oct 18, 2025 at 08:32:24PM -0400, Corey Huinker wrote:
> Rebased again.
Hearing an opinion from Fujita-san would be interesting here, so I am
adding him in CC. I have been looking a little bit at this patch.
+ ImportStatistics_function ImportStatistics;
All FDW callbacks are docum
On Fri, Sep 12, 2025 at 1:17 AM Corey Huinker
wrote:
> Rebased.
>
Rebased again.
From f44b3223c1a15fd7213b2227669ff400f8c01efa Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Thu, 7 Aug 2025 23:58:38 -0400
Subject: [PATCH v3] Add remote statistics fetching to postgres_fdw.
This adds the abi
Rebased.
From 85f4d02ccef96d80063457a7870caf5f94e12859 Mon Sep 17 00:00:00 2001
From: Corey Huinker
Date: Thu, 7 Aug 2025 23:58:38 -0400
Subject: [PATCH v2] Add remote statistics fetching to postgres_fdw.
This adds the ability to fetch and import statistics from a remote
server table table rather
>
>
> This isn't a full review. I looked at the patches mainly to find out
> how does it fit into the current method of analysing a foreign table.
>
Any degree of review is welcome. We're chasing views, reviews, etc.
> Right now, do_analyze_rel() is called with FDW specific acquireFunc,
> which
On Tue, Aug 12, 2025 at 10:33 PM Corey Huinker wrote:
>
>
> Attached is my current work on adding remote fetching of statistics to
> postgres_fdw, and opening the possibility of doing so to other foreign data
> wrappers.
>
> This involves adding two new options to postgres_fdw at the server and
Attached is my current work on adding remote fetching of statistics to
postgres_fdw, and opening the possibility of doing so to other foreign data
wrappers.
This involves adding two new options to postgres_fdw at the server and
table level.
The first option, fetch_stats, defaults to true at both
14 matches
Mail list logo
