On Wed, Jul 23, 2025 at 7:38 PM Etsuro Fujita wrote:
> I think a simple fix for this is to teach the system that the foreign
> table is a partitioned table; in more detail, I would like to propose
> to 1) add to postgres_fdw a table option, inherited, to indicate
> whether the foreig
On Sat, Jul 26, 2025 at 5:49 AM Tom Lane wrote:
> Pushed the larger patchset now. I had to do a little more work
> to get it to play with 112faf137, but it wasn't hard.
Thanks for working on this!
Best regards,
Etsuro Fujita
On Fri, Jul 25, 2025 at 7:59 PM Ashutosh Bapat
wrote:
> On Fri, Jul 25, 2025 at 3:22 PM Etsuro Fujita wrote:
> > On Thu, Jul 24, 2025 at 12:06 AM Ashutosh Bapat
> > wrote:
> > > On Wed, Jul 23, 2025 at 4:16 PM Etsuro Fujita
> > > wrote:
> > > >
Hi Ashutosh,
On Thu, Jul 24, 2025 at 12:06 AM Ashutosh Bapat
wrote:
> On Wed, Jul 23, 2025 at 4:16 PM Etsuro Fujita wrote:
> > On Tue, Jul 15, 2025 at 4:55 PM Etsuro Fujita
> > wrote:
> > > Another thing I noticed about transition tables is that while we
> > &
On Tue, Jul 15, 2025 at 4:55 PM Etsuro Fujita wrote:
> Another thing I noticed about transition tables is that while we
> prohibit transition tables on views/foreign tables, there is no
> description about that in the user-facing documentation. So I would
> like to propose to do
given
operation is an update/delete on such a foreign table. Attached is a
WIP patch for that. I think it is the user's responsibility to set
the option properly, but we could modify postgresImportForeignSchema()
to support that. Also, I think this would be back-patchable.
What do you
is called from
ATExecAttachPartition() (or ATExecAddInherit()), fails to check that
such an incompatible trigger is a row trigger, erroneously detecting a
statement trigger. Attached is a fix for that.
Best regards,
Etsuro Fujita
fix-oversight-in-FindTriggerIncompatibleWithInheritance.patch
Description: Binary data
regards,
Etsuro Fujita
0002-Update-documentation-about-transition-tables.patch
Description: Binary data
Amit-san,
On Thu, Jul 10, 2025 at 11:54 PM Amit Langote wrote:
> On Thu, Jul 10, 2025 at 22:20 Amit Langote wrote:
>> On Wed, Jul 9, 2025 at 5:07 PM Etsuro Fujita wrote:
>> > Here is an updated version of the patch, in which I added 1) an Assert
>> > to ExecAR* f
That is it. I will do the rest of the review in Commitfest PG19-2 (as
this was registered for it).
Best regards,
Etsuro Fujita
On Tue, Jul 1, 2025 at 11:55 AM Etsuro Fujita wrote:
> So I would
> like to propose to fix this by the following: 1) disable using direct
> modify to modify foreign-table partitions if there are any
> transition-table triggers on the partitioned table, and then 2) throw
&
to get more feedback from developers.
Best regards,
Etsuro Fujita
On Fri, Jul 4, 2025 at 2:41 PM Etsuro Fujita wrote:
> On Wed, Jun 18, 2025 at 8:33 PM Ranier Vilela wrote:
> > Em qua., 18 de jun. de 2025 às 07:29, Etsuro Fujita
> > escreveu:
> >> Considering fpextra cannot be NULL, I think the proposed change is
> >> some
On Wed, Jun 18, 2025 at 8:33 PM Ranier Vilela wrote:
> Em qua., 18 de jun. de 2025 às 07:29, Etsuro Fujita
> escreveu:
>> On Tue, Jun 17, 2025 at 11:03 PM Fujii Masao
>> wrote:
>> > On 2025/06/17 20:37, Ranier Vilela wrote:
>> > > Em ter., 17
On Wed, Jul 2, 2025 at 10:05 PM Amit Langote wrote:
> On Wed, Jul 2, 2025 at 7:05 PM Etsuro Fujita wrote:
> > On Tue, Jul 1, 2025 at 4:42 PM Amit Langote wrote:
> > > On Tue, Jul 1, 2025 at 11:55 AM Etsuro Fujita
> > > wrote:
> > > > While working on
Hi Amit-san,
On Tue, Jul 1, 2025 at 4:42 PM Amit Langote wrote:
> On Tue, Jul 1, 2025 at 11:55 AM Etsuro Fujita wrote:
> > While working on something else, I noticed that while we disallow
> > transition tables on foreign tables, we allow transition tables on
> > partitione
his by the following: 1) disable using direct
modify to modify foreign-table partitions if there are any
transition-table triggers on the partitioned table, and then 2) throw
an error in ExecARInsertTriggers()/ExecARUpdateTriggers()/ExecARDeleteTriggers()
if they collects transition tuple(s) f
On Tue, Jun 17, 2025 at 11:03 PM Fujii Masao
wrote:
> On 2025/06/17 20:37, Ranier Vilela wrote:
> > Em ter., 17 de jun. de 2025 às 06:09, Etsuro Fujita
> > mailto:etsuro.fuj...@gmail.com>> escreveu:
> > On Tue, Jun 17, 2025 at 2:38 PM Fujii Masao
> > m
ch this code path with
> fpextra == NULL, but I agree the current code is fragile.
> So I think it's a good idea to add the check before accessing
> the field.
We get here only when called from add_foreign_ordered_paths() or
add_foreign_final_paths(), in which cases fpextra is always set, so it
cannot be NULL. No?
Best regards,
Etsuro Fujita
e`.
> This would ensure that the foreign partitions are checked only when they are
> actually targeted by the operation.
The proposed change would make the behavior consistent with the cases
for INSERT/COPY into partitioned tables with non-insertable
foreign-table partitions, so +1 in general. (I have not looked at the
patch in detail yet.)
Best regards,
Etsuro Fujita
On Thu, Jun 5, 2025 at 7:40 PM Etsuro Fujita wrote:
> I will revert this in a few days.
Done.
Best regards,
Etsuro Fujita
On Thu, Jun 5, 2025 at 3:39 AM Robert Haas wrote:
> On Tue, Jun 3, 2025 at 6:45 AM Etsuro Fujita wrote:
> > No, this is a fix, not a feature, as discussed in the thread; as
> > mentioned in the commit message, the previous version of postgres_fdw
> > could cause surprising
a behavior change, so I think it’s a
good idea to add a note about that to the v18 release notes, as
proposed by Fujii-san.
Thank you for the comments!
Best regards,
Etsuro Fujita
On Sun, May 25, 2025 at 2:39 PM Etsuro Fujita wrote:
> Here is a new version of the patch where I added a comment for a new
> function, fixed indentation, and added the commit message. If there
> are no objections, I will push this as a master-only fix, as noted in
> the commit mess
sterResetCallback, so that there's
> not hazards of minor-version skew between postgres_fdw and the
> main backend.
Seems reasonable.
Thanks for updating the patch (and pushing it in all supported versions)!
Best regards,
Etsuro Fujita
On Thu, May 8, 2025 at 5:50 PM Etsuro Fujita wrote:
> Attached is an updated version of the patch.
Here is a new version of the patch where I added a comment for a new
function, fixed indentation, and added the commit message. If there
are no objections, I will push this as a master-only
that would be
also useful if extending batch INSERT to cases with RETURNING data in
postgres_fdw.
Thanks for working on this!
Best regards,
Etsuro Fujita
On Sun, May 4, 2025 at 9:30 PM Etsuro Fujita wrote:
> As read-only
> subtransactions can’t change to read-write, and a read-only
> main-transaction can’t change to read-write after first snapshot,
> either (note: begin_remote_xact is called after it), all we need to do
> is tr
On Sun, Mar 30, 2025 at 7:14 PM Etsuro Fujita wrote:
> On Thu, Mar 27, 2025 at 1:25 PM Ashutosh Bapat
> wrote:
> > On Tue, Mar 25, 2025 at 4:01 PM Etsuro Fujita
> > wrote:
> > > In the patch I also fixed a bug; I trusted XactReadOnly to see if the
> > > l
On Sun, Apr 6, 2025 at 8:35 PM Etsuro Fujita wrote:
> I will push the patch as well.
I pushed this one too.
Thanks!
Best regards,
Etsuro Fujita
On Mon, Apr 7, 2025 at 6:50 PM Etsuro Fujita wrote:
> On Sun, Apr 6, 2025 at 11:44 PM Michael Paquier wrote:
> > Could you also backpatch that down to v15? It
> > would be good to keep this level of comment documentation consistent
> > across all branches.
>
> S
On Sun, Apr 6, 2025 at 11:44 PM Michael Paquier wrote:
> On Sun, Apr 06, 2025 at 01:31:50PM +0200, Etsuro Fujita wrote:
> > +1 for both suggestions. So I modified the comment as such in each
> > file with such a flush_cb function. I will push the patch.
>
> Thanks for the
On Sun, Mar 30, 2025 at 10:47 PM Gurjeet Singh wrote:
> On Sun, Mar 30, 2025 at 4:31 AM Heikki Linnakangas wrote:
> > On 30/03/2025 13:23, Etsuro Fujita wrote:
> > > While working on something else I noticed $SUBJECT: we are allocating
> > > more memory than necessary
On Sun, Mar 30, 2025 at 7:54 PM Gurjeet Singh wrote:
> On Sun Mar 30, 2025 at 4:39 AM PDT, Heikki Linnakangas wrote:
> > On 30/03/2025 14:32, Heikki Linnakangas wrote:
> >> On 30/03/2025 13:28, Etsuro Fujita wrote:
> >>> Another thing I noticed is $SUBJE
Another thing I noticed is $SUBJECT: I think “if lock could not
immediately acquired” should be “if lock could not be immediately
acquired”. Attached is a patch for that.
Best regards,
Etsuro Fujita
fix-typo-in-comment.patch
Description: Binary data
large number of variables stats, so
I fixed it. Attached is a patch for that.
Best regards,
Etsuro Fujita
fix-thinko-in-pgstat_build_snapshot.patch
Description: Binary data
On Thu, Mar 27, 2025 at 1:25 PM Ashutosh Bapat
wrote:
> On Tue, Mar 25, 2025 at 4:01 PM Etsuro Fujita wrote:
> > In the patch I also fixed a bug; I trusted XactReadOnly to see if the
> > local transaction is READ ONLY, but I noticed that that is not 100%
> > correct, becaus
On Mon, Mar 3, 2025 at 1:51 PM Ashutosh Bapat
wrote:
> On Sun, Mar 2, 2025 at 5:14 PM Etsuro Fujita wrote:
> > postgres_fdw opens remote transactions in read/write mode in a local
> > transaction even if the local transaction is read-only. I noticed
> > that this leads t
On Mon, Mar 3, 2025 at 4:49 PM Tom Lane wrote:
> Ashutosh Bapat writes:
> > On Sun, Mar 2, 2025 at 5:14 PM Etsuro Fujita
> > wrote:
> >> To avoid that, I would like to propose a server option,
> >> inherit_read_only, to open the remote transactions in
On Sun, Mar 2, 2025 at 12:44 PM Etsuro Fujita wrote:
> Attached is a small patch for these options. I will add this to the
> March commitfest as it is still open.
The CF was changed to in-progress just before, so I added it to the next CF.
Best regards,
Etsuro Fujita
pose a server option, inherit_deferrable, to
open the remote transactions in deferrable mode if the local
transaction is deferrable.
Attached is a small patch for these options. I will add this to the
March commitfest as it is still open.
Best regards,
Etsuro Fujita
Inherit-xact-properties-i
query uses simple query protocol, we can
avoid the extra communication by sending the two queries in a single
function call. I will do that in the next version.
Thanks for the comment!
Best regards,
Etsuro Fujita
if such open
cursors exist on the main server, so cursor foo is guaranteed to scan
ft2 using the same snapshot that was used to scan ft1.
Thank you for taking the time for this proposal!
Best regards,
Etsuro Fujita
'bar');
S2: SELECT * FROM ft1;
c1
-
foo
bar
(2 rows)
The SELECT query retrieves both rows!
Comments welcome! Maybe I am missing something, though.
Best regards,
Etsuro Fujita
postgres_fdw-emulate-RC-behavior-WIP.patch
Description: Binary data
ame is Kouhei.
Thanks!
Best regards,
Etsuro Fujita
On Tue, Aug 20, 2024 at 8:55 AM Bruce Momjian wrote:
> I think it is an improvement, so applied to master. Thanks.
Thanks for taking care of this!
Best regards,
Etsuro Fujita
On Thu, Aug 15, 2024 at 9:56 AM Jeff Davis wrote:
> Is there any sample code that implements late locking for a FDW? I'm
> not quite clear on how it's supposed to work.
See the patch in [1]. It would not apply to HEAD anymore, though.
Best regards,
Etsuro Fujita
[1] https://ww
rify that
> such cases work. I'm not volunteering to make that happen, though.
+1 to both. Unfortunately, I do not think I will have time for that, though.
Best regards,
Etsuro Fujita
On Tue, Aug 13, 2024 at 12:15 PM Fujii Masao
wrote:
> On 2024/08/09 17:49, Etsuro Fujita wrote:
> > I just thought consolidating the information to one place would make
> > the documentation more readable.
>
> Yes, so I think that adding a note about the required remote se
and the latter part a little bit like:
However, the ON CONFLICT DO NOTHING clause is supported, provided a
unique index inference specification is omitted and the remote server
is 9.5 or later.
I just thought consolidating the information to one place would make
the documentation more readable.
Best regards,
Etsuro Fujita
are returned by the query;
> in the case of a join query, the rows locked are those that contribute
> to returned join rows."
Yeah, but I think this holds true for SELECT queries postgres_fdw
sends to the remote side. :)
Best regards,
Etsuro Fujita
Hi,
On Wed, Jul 31, 2024 at 8:55 AM Andy Fan wrote:
> Etsuro Fujita writes:
> > I noticed $SUBJECT while working on something else:
> >
> > /*
> > * Where we store tuples for a held cursor or a PORTAL_ONE_RETURNING or
> > * PORTAL_UTIL_SELECT query
query.". Attached is a
patch for that.
Best regards,
Etsuro Fujita
update-comment.patch
Description: Binary data
On Fri, Jul 5, 2024 at 9:56 PM Etsuro Fujita wrote:
> On Tue, Oct 24, 2023 at 8:48 PM Devrim Gündüz wrote:
> > I'm seeing an issue after upgrading from 12.13 to 15.4. This happens
> > when we run a query against a foreign table (fdw on the same instance to
> > a diffe
tus = 'A'
> AND tbl.table_id <> 1
> AND tbl.table_id <> - 2
>
> Any hints?
The error occurs when rescanning a postgres_fdw foreign relation, so I
think the reason why the query works would be that the planner chose a
join plan other than a nestloop joi
Hi Andres,
On Fri, Apr 12, 2024 at 1:29 AM Andres Freund wrote:
> On 2024-03-22 21:15:45 +0900, Etsuro Fujita wrote:
> > While working on [1], I noticed $SUBJECT: WaitLatchOrSocket in back
> > branches is ignoring the possibility of failing partway through, too.
> > I adde
On Wed, Apr 10, 2024 at 8:51 PM Etsuro Fujita wrote:
> We updated $SUBJECT in back branches to make it clear (see commit
> f6f61a4bd), so I would like to propose to do so in HEAD as well for
> consistency. Attached is a patch for that.
Pushed.
Best regards,
Etsuro Fujita
On Fri, Apr 5, 2024 at 7:55 PM Etsuro Fujita wrote:
> I am planning to back-patch these next week.
Done.
Best regards,
Etsuro Fujita
Hi,
We updated $SUBJECT in back branches to make it clear (see commit
f6f61a4bd), so I would like to propose to do so in HEAD as well for
consistency. Attached is a patch for that.
Best regards,
Etsuro Fujita
postgres-fdw-comment.patch
Description: Binary data
I think the first is desirable for reasons of general sanity, and the
> second for best compatibility with old versions.
>
> So I vote for "both".
+1 for both (assuming that the latter does not make the postgres_fdw
code complicated).
Best regards,
Etsuro Fujita
On Fri, Mar 22, 2024 at 9:15 PM Etsuro Fujita wrote:
> While working on [1], I noticed $SUBJECT: WaitLatchOrSocket in back
> branches is ignoring the possibility of failing partway through, too.
> I added a PG_FAINALLY block to that function, like commit 555276f85.
> Patch attached
On Fri, Mar 22, 2024 at 9:30 PM Etsuro Fujita wrote:
> If there are no objections, I will apply the patch to HEAD only.
Done.
Best regards,
Etsuro Fujita
On Fri, Mar 22, 2024 at 9:09 PM Etsuro Fujita wrote:
> On Fri, Mar 22, 2024 at 7:23 PM Alexander Pyhalov
> wrote:
> > The updated patch still looks good to me.
>
> I am planning to apply the patch to the back branches next week.
Pushed. Sorry for the delay.
Best regards,
Etsuro Fujita
assertion ensuring that the query string is non-NULL.
(I added the assertion to pgfdw_exec_cleanup_query_begin() as well.)
Attached is a patch for that.
If there are no objections, I will apply the patch to HEAD only.
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message-id
Hi,
While working on [1], I noticed $SUBJECT: WaitLatchOrSocket in back
branches is ignoring the possibility of failing partway through, too.
I added a PG_FAINALLY block to that function, like commit 555276f85.
Patch attached.
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message
Hi Alexander,
On Fri, Mar 22, 2024 at 7:23 PM Alexander Pyhalov
wrote:
> The updated patch still looks good to me.
Great! I am planning to apply the patch to the back branches next week.
Thanks for the review!
Best regards,
Etsuro Fujita
On Sun, Feb 25, 2024 at 6:34 PM Etsuro Fujita wrote:
> > On Fri, Feb 23, 2024 at 01:21:14PM +0300, Alexander Pyhalov wrote:
> > > Recent commit 555276f8594087ba15e0d58e38cd2186b9f39f6d introduced final
> > > cleanup of node->as_eventset in ExecAppendAsyncEventWait(
Hi Michael-san,
On Mon, Mar 11, 2024 at 8:12 AM Michael Paquier wrote:
> On Mon, Feb 26, 2024 at 04:29:44PM +0900, Etsuro Fujita wrote:
> > Will do. (I was thinking you would get busy from now on.)
>
> Fujita-san, have you been able to look at this thread?
Yeah, I took a look;
a fix for resource leaks in my commit 27e1f1456.
> Anyway, if you want to address it yourself, feel free to go ahead,
> thanks! I would have done it but I've been busy with life stuff for
> the last couple of days.
Will do. (I was thinking you would get busy from now on.)
Best regards,
Etsuro Fujita
> I'll look into fixing that where appropriate.
Thanks for taking care of this, Michael-san! This would result
originally from my fault, so If you don't mind, could you let me do
that?
Best regards,
Etsuro Fujita
On Fri, Nov 3, 2023 at 6:53 PM Etsuro Fujita wrote:
> On Thu, Nov 2, 2023 at 10:20 PM Daniel Gustafsson wrote:
> > > On 2 Nov 2023, at 13:40, Etsuro Fujita wrote:
> > > Attached is a small patch for that: s/heapam_visibility.c/snapmgr.c/.
> >
> > No objec
On Thu, Nov 2, 2023 at 10:20 PM Daniel Gustafsson wrote:
> > On 2 Nov 2023, at 13:40, Etsuro Fujita wrote:
> > Attached is a small patch for that: s/heapam_visibility.c/snapmgr.c/.
>
> No objections to the patch, the change is correct. However, with git grep and
> ct
sibility.c/snapmgr.c/.
Best regards,
Etsuro Fujita
fix-file-reference-in-comment.patch
Description: Binary data
eturn a
> negative value, which may occur on some production servers.
>
> Fix by changing the Assertion into a real test, to protect the
> simple_rel_array array.
Thanks for the report and patch! I will review the patch.
Best regards,
Etsuro Fujita
Hi,
On Wed, Sep 20, 2023 at 7:49 PM David Rowley wrote:
> On Wed, 20 Sept 2023 at 22:06, Etsuro Fujita wrote:
> > So I would like to propose to extend the comment to explain what they
> > can do, as in the comment about set_rel_pathlist_hook() in allpaths.c.
> > Attache
Hi,
On Thu, Sep 21, 2023 at 11:49 AM Lepikhov Andrei
wrote:
> On Wed, Sep 20, 2023, at 5:05 PM, Etsuro Fujita wrote:
> > What I am concerned about from the report [1] is that this comment is
> > a bit too terse; it might cause a misunderstanding that extensions can
> > do
that.
Best regards,
Etsuro Fujita
[1]
https://www.postgresql.org/message-id/CACawEhV%3D%2BQ0HXrcDergbTR9EkVFukgRPMTZbRFL-YK5CRmvYag%40mail.gmail.com
update-set_join_pathlist_hook-comment.patch
Description: Binary data
Hi Richard,
On Wed, Aug 30, 2023 at 11:05 AM Richard Guo wrote:
> On Tue, Aug 29, 2023 at 5:08 PM Etsuro Fujita wrote:
>> Another thing I would like to propose is minor adjustments to the docs
>> related to parallel query:
>>
>> A custom scan provider will typ
On Wed, Aug 16, 2023 at 6:45 PM Etsuro Fujita wrote:
> On Wed, Aug 16, 2023 at 9:41 AM Richard Guo wrote:
> > On Tue, Aug 15, 2023 at 7:50 PM Etsuro Fujita
> > wrote:
> >> So we should have modified the second one as well? Attached is a
> >> small patch for th
On Thu, Aug 3, 2023 at 6:01 PM Etsuro Fujita wrote:
> On Mon, Jul 31, 2023 at 7:05 PM Etsuro Fujita wrote:
> > While working on [1], I noticed $SUBJECT:
Another thing I would like to propose is minor adjustments to the docs
related to parallel query:
A custom scan provider will
e this to think about it.
Reverting the commit would resolve your issue, but re-introduce the
issue mentioned upthread to extensions that use the hook properly, so
I do not think that reverting the commit would be a fair action.
Sorry for the delay.
Best regards,
Etsuro Fujita
list. I think they are all in
the right order (ie, the given-name-followed-by-surname order).
Thanks!
Best regards,
Etsuro Fujita
Sorry, I hit the send button by mistake.
On Sun, Aug 20, 2023 at 4:34 AM Andres Freund wrote:
> On 2023-08-19 20:09:25 +0900, Etsuro Fujita wrote:
> > * The problem we had with the set_join_pathlist_hook hook is that in
> > such a typical use case, previously, if the replace
Hi,
On Sun, Aug 20, 2023 at 4:34 AM Andres Freund wrote:
>
> Hi,
>
> On 2023-08-19 20:09:25 +0900, Etsuro Fujita wrote:
> > Maybe my explanation was not enough, so let me explain:
> >
> > * I think you could use the set_join_pathlist_hook hook as you like at
&g
h I guess are the majority of the hook extensions, need not
be modified/recompiled. I think it is unfortunate that that breaks
the use case of the Citus extension, though.
BTW: commit 9e9931d2b removed the restriction on the call to the hook
extensions, so you might want to back-patch it. Though, I think it
would be better if the hook was well implemented from the beginning.
Best regards,
Etsuro Fujita
Hi Richard,
On Wed, Aug 16, 2023 at 9:41 AM Richard Guo wrote:
> On Tue, Aug 15, 2023 at 7:50 PM Etsuro Fujita wrote:
>> So we should have modified the second one as well? Attached is a
>> small patch for that.
> Agreed, nice catch! +1 to the patch.
Thanks for looking!
Be
familiar with the Citus extension, but such pseudoconstant
clauses are handled within the Citus extension?
Thanks for the report!
Best regards,
Etsuro Fujita
c6,
r1.c7, r1.c8, r2."C 1", r2.c2, r2.c3, r2.c4, r2.c5, r2.c6, r2.c7,
r2.c8 FROM ("S 1"."T 1" r1 INNER JOIN "S 1"."T 1" r2 ON (((r1.c2 =
r2."C 1")) AND ((r1."C 1" = 47
(4 rows)
So we should have modified the second one as
On Tue, Aug 8, 2023 at 6:30 PM Richard Guo wrote:
> On Tue, Aug 8, 2023 at 4:40 PM Etsuro Fujita wrote:
>> I modified the code a bit further to use an if-test to avoid a useless
>> function call, and added/tweaked comments and docs further. Attached
>> is a new versio
Hi Richard,
On Mon, Jul 31, 2023 at 5:52 PM Richard Guo wrote:
> On Fri, Jul 28, 2023 at 4:56 PM Etsuro Fujita wrote:
>> here is a rebased version of the second patch, in which I modified the
>> ForeignPath and CustomPath cases in reparameterize_path_by_child() to
>> re
On Mon, Jul 31, 2023 at 7:05 PM Etsuro Fujita wrote:
> While working on [1], I noticed $SUBJECT: commit e7cb7ee14 failed to
> update comments for the CustomPath struct in pathnodes.h, and commit
> f49842d1e failed to update docs about custom scan path callbacks in
> custom-sca
separately for ease of review (patch
update-custom-scan-path-comments.patch for the former and patch
update-custom-scan-path-docs.patch for the latter). In the second
patch I used almost the same text as for the
ReparameterizeForeignPathByChild callback function in fdwhandler.sgml.
Best regards,
Etsuro
Hi Richard,
On Mon, Jul 24, 2023 at 11:45 AM Richard Guo wrote:
> On Fri, Jul 21, 2023 at 8:51 PM Etsuro Fujita wrote:
>> * In this bit I changed the last argument to NIL, which would be
>> nitpicking, though.
>>
>> @@ -1038,7 +1038,7 @@ postgresGetForeignPaths(Plann
Hi Richard,
On Sun, Jun 25, 2023 at 3:05 PM Richard Guo wrote:
> On Wed, Jun 14, 2023 at 2:49 PM Etsuro Fujita wrote:
>> On Mon, Jun 5, 2023 at 10:19 PM Etsuro Fujita
>> wrote:
>> > To avoid this issue, I am wondering if we should modify
>> > add_paths_to_join
On Mon, Jun 5, 2023 at 10:19 PM Etsuro Fujita wrote:
> To avoid this issue, I am wondering if we should modify
> add_paths_to_joinrel() in back branches so that it just disallows the
> FDW to consider pushing down joins when the restrictlist has
> pseudoconstant clauses. Attached is
type of query execution won't make any difference. No comparison of plans to
> be selected based on total cost of two plans old (Nested Loop with Foreign
> Scans) & new (Only Foreign Scan) will be done, because we are avoiding the
> call to "postgresGetForeignJoinPaths()" up front when we have pseudo
> constants.
Thanks for looking!
Best regards,
Etsuro Fujita
Hi Richard,
On Tue, Jun 6, 2023 at 12:20 PM Richard Guo wrote:
> On Mon, Jun 5, 2023 at 9:19 PM Etsuro Fujita wrote:
>> To avoid this issue, I am wondering if we should modify
>> add_paths_to_joinrel() in back branches so that it just disallows the
>> FDW to consider pushin
shing down joins when the restrictlist has
pseudoconstant clauses. Attached is a patch for that.
My apologies for not reviewing your patch and the long long delay.
Best regards,
Etsuro Fujita
disallow-join-pushdown-if-pseudoconstants.patch
Description: Binary data
On Mon, Apr 24, 2023 at 3:31 PM Nishant Sharma
wrote:
> Any updates? -- did you get a chance to look into this?
Sorry, I have not looked into this yet, because I have been busy with
some other work recently. I plan to do so early next week.
Best regards,
Etsuro Fujita
On Fri, Apr 14, 2023 at 11:28 PM Fujii Masao
wrote:
> On 2023/04/14 18:59, Etsuro Fujita wrote:
> >> The primary message basically should avoid reference to implementation
> >> details such as specific structure names like PGcancel, shouldn't it, as
> >>
1 - 100 of 834 matches
Mail list logo
