Re: Optimizing nested ConvertRowtypeExpr execution - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Optimizing nested ConvertRowtypeExpr execution
Date
Msg-id CA+q6zcWeV1hGD3P=gzppeUoCAcyCCS5K-qvAxrZtWCqkD8VE2Q@mail.gmail.com
Whole thread Raw
In response to Re: Optimizing nested ConvertRowtypeExpr execution  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Responses Re: Optimizing nested ConvertRowtypeExpr execution
List pgsql-hackers
> On Mon, 9 Apr 2018 at 14:16, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote:
>
> On Mon, Apr 9, 2018 at 5:34 PM, Kyotaro HORIGUCHI
> <horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> >
> > The new code doesn't seem to work as written.
> >
> >>   arg = eval_const_expressions_mutator((Node *) cre->arg,
> >>                                        context);
> >>
> >>   /*
> >>    * In case of a nested ConvertRowtypeExpr, we can convert the
> >>    * leaf row directly to the topmost row format without any
> >>    * intermediate conversions.
> >>    */
> >>   while (arg != NULL && IsA(arg, ConvertRowtypeExpr))
> >>       arg = (Node *) castNode(ConvertRowtypeExpr, arg)->arg;
> >
> > This runs depth-first so the while loop seems to run at most
> > once. I suppose that the "arg =" and the while loop are
> > transposed as intention.
>
> Yes. I have modelled it after RelableType case few lines above in the
> same function.

This patch went through the last tree commit fests without any noticeable
activity, but cfbot says it still applies and doesn't break any tests. The
patch itself is rather small, and I could reproduce ~20% of performance
improvements while running the same scripts under pgbench (although not in all
cases), but probably we need to find someone to take over it. Does anyone wants
to do so, maybe Kyotaro?


pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)
Next
From: Dmitry Dolgov
Date:
Subject: Re: using index or check in ALTER TABLE SET NOT NULL