On Tue, Jul 11, 2023 at 4:30 PM Tom Lane wrote:
>
> Jeevan Chalke writes:
> > Attached patch.
>
> I would be astonished if this fixes anything. The code still doesn't
> know which paths are referenced by which other ones, and so the place
> where we free a previously-added path can't know what
On Tue, Jul 18, 2023 at 5:05 AM David Rowley wrote:
>
> On Mon, 17 Jul 2023 at 15:31, Tom Lane wrote:
> > > I also didn't do anything about ExtensibleNode types. I assume just
> > > copying the ExtensibleNode isn't good enough. To flat copy the actual
> > > node I think would require adding a
On Mon, 17 Jul 2023 at 15:31, Tom Lane wrote:
> > I also didn't do anything about ExtensibleNode types. I assume just
> > copying the ExtensibleNode isn't good enough. To flat copy the actual
> > node I think would require adding a new function to
> > ExtensibleNodeMethods.
>
> Yeah, the problem
David Rowley writes:
> On Wed, 12 Jul 2023 at 14:50, David Rowley wrote:
>> On Wed, 12 Jul 2023 at 14:23, Tom Lane wrote:
>>> I did think about that, but "shallow copy a Path" seems nontrivial
>>> because the Path structs are all different sizes. Maybe it is worth
>>> building some
On Wed, 12 Jul 2023 at 14:50, David Rowley wrote:
>
> On Wed, 12 Jul 2023 at 14:23, Tom Lane wrote:
> > I did think about that, but "shallow copy a Path" seems nontrivial
> > because the Path structs are all different sizes. Maybe it is worth
> > building some infrastructure to support that?
>
On Wed, 12 Jul 2023 at 14:23, Tom Lane wrote:
> I did think about that, but "shallow copy a Path" seems nontrivial
> because the Path structs are all different sizes. Maybe it is worth
> building some infrastructure to support that?
It seems a reasonable thing to have to do. It seems the
David Rowley writes:
> I've not taken the time to fully understand this, but from reading the
> thread, I'm not immediately understanding why we can't just shallow
> copy the Path from the other RelOptInfo and replace the parent before
> using it in the upper RelOptInfo. Can you explain?
I did
On Wed, 12 Jul 2023 at 08:46, Tom Lane wrote:
> A low-cost fix perhaps could be to unlink the lower rel's whole
> path list (set input_rel->pathlist = NIL, also zero the related
> fields such as cheapest_path) once we've finished selecting the
> paths we want for the upper rel. That's not great
So what's going on here is that create_ordered_paths() does this:
foreach(lc, input_rel->pathlist)
{
Path *input_path = (Path *) lfirst(lc);
if (/* input path is suitably sorted already */)
sorted_path = input_path;
else
/* build a
Hi Tom,
On Tue, Jul 11, 2023 at 4:30 PM Tom Lane wrote:
> Jeevan Chalke writes:
> > Attached patch.
>
> I would be astonished if this fixes anything. The code still doesn't
> know which paths are referenced by which other ones, and so the place
> where we free a previously-added path can't
Jeevan Chalke writes:
> Attached patch.
I would be astonished if this fixes anything. The code still doesn't
know which paths are referenced by which other ones, and so the place
where we free a previously-added path can't know what to do.
I've speculated about adding some form of reference
On Tue, Jul 11, 2023 at 2:58 PM Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Tue, Jul 11, 2023 at 1:19 PM Alvaro Herrera
> wrote:
>
>> On 2023-Jul-11, Jeevan Chalke wrote:
>>
>> > 4. However, 2nd path was already sorted and passed as is to the
>> add_path().
>> > 5. add_path()
On Tue, Jul 11, 2023 at 1:19 PM Alvaro Herrera
wrote:
> On 2023-Jul-11, Jeevan Chalke wrote:
>
> > 4. However, 2nd path was already sorted and passed as is to the
> add_path().
> > 5. add_path() decides to reject this new path on some metrics. However,
> in
> > the end, it pfree() this passed in
On 2023-Jul-11, Jeevan Chalke wrote:
> 4. However, 2nd path was already sorted and passed as is to the add_path().
> 5. add_path() decides to reject this new path on some metrics. However, in
> the end, it pfree() this passed in path. It seems wrong as its references
> do present elsewhere. For
Hello,
While debugging one issue, we have added the below line in
postgresGetForeignPlan() to see the foreignrel details.
@@ -1238,6 +1238,8 @@ postgresGetForeignPlan(PlannerInfo *root,
boolhas_limit = false;
ListCell *lc;
+ elog(INFO, "foreignrel: %s",
15 matches
Mail list logo
