On Wed, Oct 28, 2020 at 4:46 PM Amit Langote wrote:
>
> On Tue, Oct 27, 2020 at 10:23 PM Heikki Linnakangas wrote:
> > This patch looks reasonable to me at a quick glance. I'm a bit worried
> > or unhappy about the impact on FDWs, though. It doesn't seem nice that
> > the ResultRelInfo is not
On Wed, Oct 28, 2020 at 12:02 PM Amit Langote wrote:
> On Tue, Oct 27, 2020 at 10:23 PM Heikki Linnakangas wrote:
> > But since this applies on top of the "overhaul update/delete processing"
> > patch, let's tackle that patch set next. Could you rebase that, please?
>
>
> Anyway, I will post the
On Tue, Oct 27, 2020 at 10:23 PM Heikki Linnakangas wrote:
> This patch looks reasonable to me at a quick glance. I'm a bit worried
> or unhappy about the impact on FDWs, though. It doesn't seem nice that
> the ResultRelInfo is not available in the BeginDirectModify call. It's
> not too bad, the
On Tue, Oct 27, 2020 at 10:23 PM Heikki Linnakangas wrote:
> On 23/10/2020 12:37, Amit Langote wrote:
> > To explain these numbers a bit, "overheaul update/delete processing"
> > patch improves the performance of that benchmark by allowing the
> > updates to use run-time pruning when executing
On 23/10/2020 12:37, Amit Langote wrote:
To explain these numbers a bit, "overheaul update/delete processing"
patch improves the performance of that benchmark by allowing the
updates to use run-time pruning when executing generic plans, which
they can't today.
However without
On Fri, Oct 23, 2020 at 4:04 PM Heikki Linnakangas wrote:
> On 22/10/2020 16:49, Amit Langote wrote:
> > On Tue, Oct 20, 2020 at 9:57 PM Amit Langote
> > wrote:
> >> On Mon, Oct 19, 2020 at 8:55 PM Heikki Linnakangas wrote:
> >>> It's probably true that there's no performance gain from
On 22/10/2020 16:49, Amit Langote wrote:
On Tue, Oct 20, 2020 at 9:57 PM Amit Langote wrote:
On Mon, Oct 19, 2020 at 8:55 PM Heikki Linnakangas wrote:
It's probably true that there's no performance gain from initializing
them more lazily. But the reasoning and logic around the initialization
On 23/10/2020 05:56, Amit Langote wrote:
On Thu, Oct 22, 2020 at 11:25 PM Alvaro Herrera wrote:
On 2020-Oct-22, Amit Langote wrote:
0001 fixes a thinko of the recent commit 1375422c782 that I discovered
when debugging a problem with 0003.
Hmm, how hard is it to produce a test case that
On Thu, Oct 22, 2020 at 11:25 PM Alvaro Herrera wrote:
>
> On 2020-Oct-22, Amit Langote wrote:
>
> > 0001 fixes a thinko of the recent commit 1375422c782 that I discovered
> > when debugging a problem with 0003.
>
> Hmm, how hard is it to produce a test case that fails because of this
> problem?
On 2020-Oct-22, Amit Langote wrote:
> 0001 fixes a thinko of the recent commit 1375422c782 that I discovered
> when debugging a problem with 0003.
Hmm, how hard is it to produce a test case that fails because of this
problem?
On Tue, Oct 20, 2020 at 9:57 PM Amit Langote wrote:
> On Mon, Oct 19, 2020 at 8:55 PM Heikki Linnakangas wrote:
> > It's probably true that there's no performance gain from initializing
> > them more lazily. But the reasoning and logic around the initialization
> > is complicated. After tracing
On Mon, Oct 19, 2020 at 8:55 PM Heikki Linnakangas wrote:
> On 17/10/2020 18:54, Alvaro Herrera wrote:
> > On 2020-Oct-17, Amit Langote wrote:
> >> As I said in my previous email, I don't see how we can make
> >> initializing the map any lazier than it already is. If a partition
> >> has a
On Mon, Oct 19, 2020 at 8:48 PM Heikki Linnakangas wrote:
> On 19/10/2020 07:54, Amit Langote wrote:
> > On Sun, Oct 18, 2020 at 12:54 AM Alvaro Herrera
> > wrote:
> >> Well, I was thinking on making the ri_PartitionInfo be about
> >> partitioning in general, not just specifically for partition
On 17/10/2020 18:54, Alvaro Herrera wrote:
On 2020-Oct-17, Amit Langote wrote:
As I said in my previous email, I don't see how we can make
initializing the map any lazier than it already is. If a partition
has a different tuple descriptor than the root table, then we know for
sure that any
On 19/10/2020 07:54, Amit Langote wrote:
On Sun, Oct 18, 2020 at 12:54 AM Alvaro Herrera wrote:
On 2020-Oct-17, Amit Langote wrote:
Hmm, I don't see ri_PartitionCheckExpr as being a piece of routing
information, because it's primarily meant to be used when inserting
*directly* into a
On Sun, Oct 18, 2020 at 12:54 AM Alvaro Herrera wrote:
> On 2020-Oct-17, Amit Langote wrote:
> > Hmm, I don't see ri_PartitionCheckExpr as being a piece of routing
> > information, because it's primarily meant to be used when inserting
> > *directly* into a partition, although it's true we do
On 2020-Oct-17, Amit Langote wrote:
> Hmm, I don't see ri_PartitionCheckExpr as being a piece of routing
> information, because it's primarily meant to be used when inserting
> *directly* into a partition, although it's true we do initialize it in
> routing target partitions too in some cases.
>
On Fri, Oct 16, 2020 at 11:45 PM Alvaro Herrera wrote:
> On 2020-Oct-16, Amit Langote wrote:
> > On Thu, Oct 15, 2020 at 11:59 PM Heikki Linnakangas wrote:
> > > On Wed, Oct 14, 2020 at 6:04 PM Heikki Linnakangas
> > > wrote:
>
> > > And if we removed
> > >
On 2020-Oct-16, Amit Langote wrote:
> On Thu, Oct 15, 2020 at 11:59 PM Heikki Linnakangas wrote:
> > On Wed, Oct 14, 2020 at 6:04 PM Heikki Linnakangas wrote:
> > And if we removed
> > ri_PartitionInfo->pi_PartitionToRootMap, and always used
> > ri_ChildToRootMap for it.
>
> Done in the
On Thu, Oct 15, 2020 at 11:59 PM Heikki Linnakangas wrote:
> On Wed, Oct 14, 2020 at 6:04 PM Heikki Linnakangas wrote:
> > I'll continue with the last couple of patches in this thread.
>
> I committed the move of the cross-partition logic to new
> ExecCrossPartitionUpdate() function, with just
On Wed, Oct 14, 2020 at 6:04 PM Heikki Linnakangas wrote:
I'll continue with the last couple of patches in this thread.
I committed the move of the cross-partition logic to new
ExecCrossPartitionUpdate() function, with just minor comment editing and
pgindent. I left out the refactoring
On Wed, Oct 14, 2020 at 6:04 PM Heikki Linnakangas wrote:
> On 14/10/2020 09:44, Amit Langote wrote:
> > I like the idea of storing the ResultRelInfo in ForeignScanState, but
> > it would be better if we can document the fact that an FDW may not
> > reliably access until IterateDirectModify().
On 14/10/2020 09:44, Amit Langote wrote:
I like the idea of storing the ResultRelInfo in ForeignScanState, but
it would be better if we can document the fact that an FDW may not
reliably access until IterateDirectModify(). That's because, setting
it in ExecInitForeignScan() will mean *all*
On Wed, Oct 14, 2020 at 1:30 AM Heikki Linnakangas wrote:
> On 13/10/2020 19:09, Heikki Linnakangas wrote:
> > One little idea I had:
> >
> > I think all FDWs that support direct modify will have to carry the
> > resultRelaton index or the ResultRelInfo pointer from BeginDirectModify
> > to
On 13/10/2020 19:09, Heikki Linnakangas wrote:
One little idea I had:
I think all FDWs that support direct modify will have to carry the
resultRelaton index or the ResultRelInfo pointer from BeginDirectModify
to IterateDirectModify in the FDW's private struct. It's not
complicated, but should
On 13/10/2020 15:03, Amit Langote wrote:
On Tue, Oct 13, 2020 at 7:13 PM Heikki Linnakangas wrote:
Ok, committed. I'll continue to look at the rest of the patches in this
patch series now.
I've reviewed the next two patches in the series, they are pretty much
ready for commit now. I made
On Tue, Oct 13, 2020 at 7:13 PM Heikki Linnakangas wrote:
> On 13/10/2020 07:32, Amit Langote wrote:
> > On Tue, Oct 13, 2020 at 1:57 AM Heikki Linnakangas wrote:
> >> It occurred to me that if we do that (initialize the array lazily),
> >> there's very little need for the
On 13/10/2020 07:32, Amit Langote wrote:
On Tue, Oct 13, 2020 at 1:57 AM Heikki Linnakangas wrote:
It occurred to me that if we do that (initialize the array lazily),
there's very little need for the PlannedStmt->resultRelations list
anymore. It's only used in ExecRelationIsTargetRelation(),
On Tue, Oct 13, 2020 at 1:57 AM Heikki Linnakangas wrote:
> On 12/10/2020 16:47, Amit Langote wrote:
> > On Mon, Oct 12, 2020 at 8:12 PM Heikki Linnakangas wrote:
> >> 1. We have many different cleanup/close routines now:
> >> ExecCloseResultRelations, ExecCloseRangeTableRelations, and
> >>
On 12/10/2020 16:47, Amit Langote wrote:
On Mon, Oct 12, 2020 at 8:12 PM Heikki Linnakangas wrote:
1. We have many different cleanup/close routines now:
ExecCloseResultRelations, ExecCloseRangeTableRelations, and
ExecCleanUpTriggerState. Do we need them all? It seems to me that we
could merge
On Mon, Oct 12, 2020 at 8:12 PM Heikki Linnakangas wrote:
> On 09/10/2020 11:01, Amit Langote wrote:
> > On Thu, Oct 8, 2020 at 9:35 PM Amit Langote wrote:
> >> On Wed, Oct 7, 2020 at 9:07 PM Heikki Linnakangas wrote:
> >>> On 07/10/2020 12:50, Amit Langote wrote:
> I have thought about
On 09/10/2020 11:01, Amit Langote wrote:
On Thu, Oct 8, 2020 at 9:35 PM Amit Langote wrote:
On Wed, Oct 7, 2020 at 9:07 PM Heikki Linnakangas wrote:
On 07/10/2020 12:50, Amit Langote wrote:
I have thought about something like this before. An idea I had is to
make es_result_relations array
On Wed, Oct 7, 2020 at 9:07 PM Heikki Linnakangas wrote:
> On 07/10/2020 12:50, Amit Langote wrote:
> > On Tue, Oct 6, 2020 at 12:45 AM Heikki Linnakangas wrote:
> >> It would be better to set it in make_modifytable(), just
> >> after calling PlanDirectModify().
> >
> > Actually, that's how it
On 07/10/2020 12:50, Amit Langote wrote:
On Tue, Oct 6, 2020 at 12:45 AM Heikki Linnakangas wrote:
It would be better to set it in make_modifytable(), just
after calling PlanDirectModify().
Actually, that's how it was done in earlier iterations but I think I
decided to move that into the
Hekki,
Thanks a lot for the review!
On Tue, Oct 6, 2020 at 12:45 AM Heikki Linnakangas wrote:
> On 13/07/2020 08:47, Amit Langote wrote:
> > It's been over 11 months since there was any significant commentary on
> > the contents of the patches themselves, so perhaps I should reiterate
> > what
On 13/07/2020 08:47, Amit Langote wrote:
It's been over 11 months since there was any significant commentary on
the contents of the patches themselves, so perhaps I should reiterate
what the patches are about and why it might still be a good idea to
consider them.
The thread started with some
On Wed, Jul 1, 2020 at 6:56 PM Daniel Gustafsson wrote:
>
> > On 2 Mar 2020, at 06:08, Amit Langote wrote:
> >
> > On Mon, Mar 2, 2020 at 4:43 AM Tom Lane wrote:
> >> Amit Langote writes:
> >>> Rebased again.
> >>
> >> Seems to need that again, according to cfbot :-(
> >
> > Thank you, done.
>
> On 2 Mar 2020, at 06:08, Amit Langote wrote:
>
> On Mon, Mar 2, 2020 at 4:43 AM Tom Lane wrote:
>> Amit Langote writes:
>>> Rebased again.
>>
>> Seems to need that again, according to cfbot :-(
>
> Thank you, done.
..and another one is needed as it no longer applies, please submit a
On Mon, Mar 2, 2020 at 4:43 AM Tom Lane wrote:
> Amit Langote writes:
> > Rebased again.
>
> Seems to need that again, according to cfbot :-(
Thank you, done.
Regards,
Amit
v10-0002-Remove-es_result_relation_info.patch
Description: Binary data
Amit Langote writes:
> Rebased again.
Seems to need that again, according to cfbot :-(
regards, tom lane
On Thu, Sep 26, 2019 at 1:56 PM Amit Langote wrote:
> On Wed, Sep 4, 2019 at 10:45 AM Amit Langote wrote:
> > On Fri, Aug 9, 2019 at 10:51 AM Amit Langote
> > wrote:
> > To avoid losing track of this, I've added this to November CF.
> >
> > https://commitfest.postgresql.org/25/2277/
> >
> >
On Wed, Sep 4, 2019 at 10:45 AM Amit Langote wrote:
> On Fri, Aug 9, 2019 at 10:51 AM Amit Langote wrote:
> To avoid losing track of this, I've added this to November CF.
>
> https://commitfest.postgresql.org/25/2277/
>
> Struggled a bit to give a title to the entry though.
Noticed that one of
On Fri, Aug 9, 2019 at 10:51 AM Amit Langote wrote:
>
> Fujita-san,
>
> On Thu, Aug 8, 2019 at 9:49 PM Etsuro Fujita wrote:
> > On Thu, Aug 8, 2019 at 10:10 AM Amit Langote
> > wrote:
> > > Attached updated patches; only 0001 changed in this version.
> >
> > Thanks for the updated version,
Hi,
On Thu, Aug 8, 2019 at 10:10 AM Amit Langote wrote:
> On Wed, Aug 7, 2019 at 6:00 PM Etsuro Fujita wrote:
> > On Wed, Aug 7, 2019 at 4:28 PM Amit Langote wrote:
> > > I just noticed obsolete references to es_result_relation_info that
> > > 0002 failed to remove. One of them is in
Fujita-san,
On Wed, Aug 7, 2019 at 6:00 PM Etsuro Fujita wrote:
> On Wed, Aug 7, 2019 at 4:28 PM Amit Langote wrote:
> > I just noticed obsolete references to es_result_relation_info that
> > 0002 failed to remove. One of them is in fdwhandler.sgml:
> >
> >
> > TupleTableSlot *
> >
Amit-san,
On Wed, Aug 7, 2019 at 4:28 PM Amit Langote wrote:
> On Wed, Aug 7, 2019 at 12:00 PM Etsuro Fujita wrote:
> > IIUC, I think we reached a consensus at least on the 0001 patch.
> > Andres, would you mind if I commit that patch?
>
> I just noticed obsolete references to
On Wed, Aug 7, 2019 at 12:00 PM Etsuro Fujita wrote:
> IIUC, I think we reached a consensus at least on the 0001 patch.
> Andres, would you mind if I commit that patch?
I just noticed obsolete references to es_result_relation_info that
0002 failed to remove. One of them is in fdwhandler.sgml:
Hi,
On Wed, Aug 7, 2019 at 11:47 AM Amit Langote wrote:
> On Wed, Aug 7, 2019 at 11:30 AM Etsuro Fujita wrote:
> > On Wed, Aug 7, 2019 at 10:24 AM Amit Langote
> > wrote:
> > > * Regarding setting ForeignScan.resultRelIndex even for non-direct
> > > modifications, maybe that's not a good idea
Fujita-san,
Thanks for the quick follow up.
On Wed, Aug 7, 2019 at 11:30 AM Etsuro Fujita wrote:
> On Wed, Aug 7, 2019 at 10:24 AM Amit Langote wrote:
> > * Regarding setting ForeignScan.resultRelIndex even for non-direct
> > modifications, maybe that's not a good idea anymore. A foreign
Amit-san,
On Wed, Aug 7, 2019 at 10:24 AM Amit Langote wrote:
> On Tue, Aug 6, 2019 at 9:56 PM Etsuro Fujita wrote:
> > What
> > I'm thinking for the setrefs.c change is to modify ForeignScan (ie,
> > set_foreignscan_references) rather than ModifyTable, like the
> > attached.
>
> Thanks for
Fujita-san,
Thanks a lot the review.
On Tue, Aug 6, 2019 at 9:56 PM Etsuro Fujita wrote:
> On Mon, Aug 5, 2019 at 6:16 PM Amit Langote wrote:
> > I first thought to set it
> > only if direct modification is being used, but maybe it'd be simpler
> > to set it even if direct modification is not
Hi,
On 2019-08-05 18:16:10 +0900, Amit Langote wrote:
> The patch adds a resultRelIndex field to ForeignScan node, which is
> set to >= 0 value for non-SELECT queries. I first thought to set it
> only if direct modification is being used, but maybe it'd be simpler
> to set it even if direct
Amit-san,
On Mon, Aug 5, 2019 at 6:16 PM Amit Langote wrote:
> On Sat, Aug 3, 2019 at 3:01 AM Andres Freund wrote:
> Based on the discussion, I have updated the patch.
>
> > I'm a bit woried about the move of BeginDirectModify() into
> > nodeModifyTable.c - it just seems like an odd control
Hi Andres, Fujita-san,
On Sat, Aug 3, 2019 at 3:01 AM Andres Freund wrote:
> On 2019-07-31 17:04:38 +0900, Amit Langote wrote:
> > I looked into trying to do the things I mentioned above and it seems
> > to me that revising BeginDirectModify()'s API to receive the
> > ResultRelInfo directly as
Amit-san,
On Mon, Aug 5, 2019 at 2:36 PM Amit Langote wrote:
> On Mon, Aug 5, 2019 at 2:31 PM Etsuro Fujita wrote:
> > On Mon, Aug 5, 2019 at 1:31 PM Amit Langote wrote:
> > > On Sun, Aug 4, 2019 at 4:45 AM Etsuro Fujita
> > > wrote:
> > > > On Sun, Aug 4, 2019 at 3:03 AM Andres Freund
Fujita-san,
Thanks for the quick follow up.
On Mon, Aug 5, 2019 at 2:31 PM Etsuro Fujita wrote:
> On Mon, Aug 5, 2019 at 1:31 PM Amit Langote wrote:
> > On Sun, Aug 4, 2019 at 4:45 AM Etsuro Fujita
> > wrote:
> > > On Sun, Aug 4, 2019 at 3:03 AM Andres Freund wrote:
> > > > On 2019-08-03
Amit-san,
On Mon, Aug 5, 2019 at 1:31 PM Amit Langote wrote:
> On Sun, Aug 4, 2019 at 4:45 AM Etsuro Fujita wrote:
> > On Sun, Aug 4, 2019 at 3:03 AM Andres Freund wrote:
> > > On 2019-08-03 13:48:01 -0400, Tom Lane wrote:
> > > > If those are the choices, adding a parameter is clearly the
Hi,
On Sun, Aug 4, 2019 at 4:45 AM Etsuro Fujita wrote:
> On Sun, Aug 4, 2019 at 3:03 AM Andres Freund wrote:
> > On 2019-08-03 13:48:01 -0400, Tom Lane wrote:
> > > If those are the choices, adding a parameter is clearly the preferable
> > > solution, because it makes the API breakage obvious
Hi,
On Sun, Aug 4, 2019 at 3:03 AM Andres Freund wrote:
> On 2019-08-03 13:48:01 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2019-08-03 19:41:55 +0900, Etsuro Fujita wrote:
> > >> What API does that function break?
> >
> > > You need to call it, whereas previously you did not need
Hi,
On 2019-08-03 13:48:01 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-08-03 19:41:55 +0900, Etsuro Fujita wrote:
> >> What API does that function break?
>
> > You need to call it, whereas previously you did not need to call it. The
> > effort to change an FDW to get one more
Andres Freund writes:
> On 2019-08-03 19:41:55 +0900, Etsuro Fujita wrote:
>> What API does that function break?
> You need to call it, whereas previously you did not need to call it. The
> effort to change an FDW to get one more parameter, or to call that
> function is about the same.
If those
Hi,
On 2019-08-03 19:41:55 +0900, Etsuro Fujita wrote:
> > I don't like
> > ExecFindResultRelInfo at all. What's the point of it? It's introduction
> > is still an API break - I don't understand why that break is better than
> > just passing the ResultRelInfo directly to BeginDirectModify()?
>
>
Hi,
On Sat, Aug 3, 2019 at 5:31 AM Andres Freund wrote:
> On 2019-08-03 05:20:35 +0900, Etsuro Fujita wrote:
> > On Sat, Aug 3, 2019 at 3:01 AM Andres Freund wrote:
> > > On 2019-07-31 17:04:38 +0900, Amit Langote wrote:
> > > > I looked into trying to do the things I mentioned above and it
Hi,
On 2019-08-01 18:38:09 +0900, Etsuro Fujita wrote:
> On Thu, Aug 1, 2019 at 10:33 AM Amit Langote wrote:
> > If it's the approach of adding a resultRelation Index field to
> > ForeignScan node, I tried and had to give up, realizing that we don't
> > maintain ResultRelInfos in an array that
Hi,
On 2019-08-03 05:20:35 +0900, Etsuro Fujita wrote:
> On Sat, Aug 3, 2019 at 3:01 AM Andres Freund wrote:
> > On 2019-07-31 17:04:38 +0900, Amit Langote wrote:
> > > I looked into trying to do the things I mentioned above and it seems
> > > to me that revising BeginDirectModify()'s API to
Hi,
On Sat, Aug 3, 2019 at 3:01 AM Andres Freund wrote:
> On 2019-07-31 17:04:38 +0900, Amit Langote wrote:
> > I looked into trying to do the things I mentioned above and it seems
> > to me that revising BeginDirectModify()'s API to receive the
> > ResultRelInfo directly as Andres suggested
Hi,
On 2019-07-31 17:04:38 +0900, Amit Langote wrote:
> I looked into trying to do the things I mentioned above and it seems
> to me that revising BeginDirectModify()'s API to receive the
> ResultRelInfo directly as Andres suggested might be the best way
> forward. I've implemented that in the
Amit-san,
On Thu, Aug 1, 2019 at 10:33 AM Amit Langote wrote:
> On Wed, Jul 31, 2019 at 9:04 PM Etsuro Fujita wrote:
> > On Wed, Jul 31, 2019 at 5:05 PM Amit Langote
> > wrote:
> > > On Tue, Jul 30, 2019 at 4:20 PM Amit Langote
> > > wrote:
> > > > On Sat, Jul 20, 2019 at 1:52 AM Andres
Fujita-san,
Thanks for the reply and sorry I didn't wait a bit more before posting
the patch.
On Wed, Jul 31, 2019 at 9:04 PM Etsuro Fujita wrote:
> On Wed, Jul 31, 2019 at 5:05 PM Amit Langote wrote:
> > On Tue, Jul 30, 2019 at 4:20 PM Amit Langote
> > wrote:
> > > On Sat, Jul 20, 2019 at
Hi,
On 2019-07-31 21:03:58 +0900, Etsuro Fujita wrote:
> I'm still not sure that it's a good idea to remove
> es_result_relation_info, but if I had to say then I think the latter
> would probably be better. I'm planning to rework on direct
> modification to base it on upper planner pathification
On Wed, Jul 31, 2019 at 5:05 PM Amit Langote wrote:
> On Tue, Jul 30, 2019 at 4:20 PM Amit Langote wrote:
> > On Sat, Jul 20, 2019 at 1:52 AM Andres Freund wrote:
> > > IOW, we should just change the direct modify calls to get the relevant
> > > ResultRelationInfo or something in that vein
On Tue, Jul 30, 2019 at 4:20 PM Amit Langote wrote:
> On Sat, Jul 20, 2019 at 1:52 AM Andres Freund wrote:
> > > The first one (0001) deals with reducing the core executor's reliance
> > > on es_result_relation_info to access the currently active result
> > > relation, in favor of receiving it
Hi Andres,
Sorry about the delay in replying as I was on vacation for the last few days.
On Sat, Jul 20, 2019 at 1:52 AM Andres Freund wrote:
> > The first one (0001) deals with reducing the core executor's reliance
> > on es_result_relation_info to access the currently active result
> >
Hi,
On 2019-07-19 17:11:10 -0400, Alvaro Herrera wrote:
> On 2019-Jul-19, Andres Freund wrote:
> > > - slot = ExecDelete(node, tupleid, oldtuple,
> > > planSlot,
> > > -
> > > >mt_epqstate, estate,
> > > +
On 2019-Jul-19, Andres Freund wrote:
> On 2019-07-19 17:52:20 +0900, Amit Langote wrote:
> > The first one (0001) deals with reducing the core executor's reliance
> > on es_result_relation_info to access the currently active result
> > relation, in favor of receiving it from the caller as a
Hi,
On 2019-07-19 17:52:20 +0900, Amit Langote wrote:
> Attached are two patches.
Awesome.
> The first one (0001) deals with reducing the core executor's reliance
> on es_result_relation_info to access the currently active result
> relation, in favor of receiving it from the caller as a
On Thu, Jul 18, 2019 at 4:50 PM Amit Langote wrote:
> On Thu, Jul 18, 2019 at 2:53 PM Andres Freund wrote:
> > On 2019-07-18 14:24:29 +0900, Amit Langote wrote:
> > > On Thu, Jul 18, 2019 at 10:09 AM Andres Freund wrote:
> > Or perhaps the actually correct fix is to remove
On Thu, Jul 18, 2019 at 4:51 PM Amit Langote wrote:
> On Thu, Jul 18, 2019 at 2:53 PM Andres Freund wrote:
> > On 2019-07-18 14:24:29 +0900, Amit Langote wrote:
> > > On Thu, Jul 18, 2019 at 10:09 AM Andres Freund wrote:
> > > > 1) How come partition routing is done outside of ExecInsert()?
> >
On Thu, Jul 18, 2019 at 2:53 PM Andres Freund wrote:
> On 2019-07-18 14:24:29 +0900, Amit Langote wrote:
> > On Thu, Jul 18, 2019 at 10:09 AM Andres Freund wrote:
> > > 1) How come partition routing is done outside of ExecInsert()?
> > >
> > > case CMD_INSERT:
> > >
Hi,
On 2019-07-18 14:24:29 +0900, Amit Langote wrote:
> On Thu, Jul 18, 2019 at 10:09 AM Andres Freund wrote:
> > 1) How come partition routing is done outside of ExecInsert()?
> >
> > case CMD_INSERT:
> > /* Prepare for tuple routing if needed. */
> >
Hi Andres,
On Thu, Jul 18, 2019 at 10:09 AM Andres Freund wrote:
> 1) How come partition routing is done outside of ExecInsert()?
>
> case CMD_INSERT:
> /* Prepare for tuple routing if needed. */
> if (proute)
> slot =
Hi,
While discussing partition related code with David in [1], I again was
confused by the layering of partition related code in
nodeModifyTable.c.
1) How come partition routing is done outside of ExecInsert()?
case CMD_INSERT:
/* Prepare for tuple routing if
82 matches
Mail list logo
