Optimizing nested ConvertRowtypeExpr execution - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Optimizing nested ConvertRowtypeExpr execution
Date
Msg-id CAFjFpReDR9EGJ18dcEjz5eey+5o-NHvZSTRZa7BbZcrjtmi8gA@mail.gmail.com
Whole thread Raw
Responses Re: Optimizing nested ConvertRowtypeExpr execution  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,
In a multi-level partitioned table, a parent whole-row reference gets
translated into nested ConvertRowtypeExpr with child whole-row
reference as the leaf. During the execution, the child whole-row
reference gets translated into all all intermediate parents' whole-row
references, ultimately represented as parent's whole-row reference.
AFAIU, the intermediate translations are unnecessary. The leaf child
whole-row can be directly translated into top parent's whole-row
reference. Here's a WIP patch which does that by eliminating
intermediate ConvertRowtypeExprs during ExecInitExprRec().

I tested the performance with two-level partitions, and 1M rows, on my
laptop selecting just the whole-row expression. I saw ~20% improvement
in the execution time. Please see the attached test and its output
with and without patch.

For two-level inheritance hierarchy, this patch doesn't show any
performance difference since the plan time hierarchy is flattened into
single level.

Instead of the approach that the patch takes, we might modify
adjust_appendrel_attrs() not to produce nested ConvertRowtypeExprs in
the first place. With that we may get rid of code which handles nested
ConvertRowtypeExprs like is_converted_whole_row_reference(). But I
haven't tried that approach yet.

Suggestions/comments welcome.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Attachment

pgsql-hackers by date:

Previous
From: Jeevan Chalke
Date:
Subject: Re: [HACKERS] Partition-wise aggregation/grouping
Next
From: Etsuro Fujita
Date:
Subject: Re: [HACKERS] Add support for tuple routing to foreign partitions