Re: Introduce list_reverse() to make lcons() usage less inefficient

2023-02-20 Thread David Rowley
On Fri, 17 Feb 2023 at 16:35, David Rowley wrote: > > On Fri, 17 Feb 2023 at 13:23, Andres Freund wrote: > > But wouldn't an even cheaper way here be to iterate over the children in > > reverse order when match_partition_order_desc? We can do that efficiently > > now. Looks like we don't have a r

Re: Introduce list_reverse() to make lcons() usage less inefficient

2023-02-16 Thread David Rowley
On Fri, 17 Feb 2023 at 13:23, Andres Freund wrote: > But wouldn't an even cheaper way here be to iterate over the children in > reverse order when match_partition_order_desc? We can do that efficiently > now. Looks like we don't have a readymade helper for it, but it'd be easy > enough to add or o

Re: Introduce list_reverse() to make lcons() usage less inefficient

2023-02-16 Thread Tom Lane
Andres Freund writes: > On 2023-02-17 11:36:40 +1300, David Rowley wrote: >> One of those places is in generate_orderedappend_paths() when we find >> that the required sort order is the same as the reverse of the >> partition order. In this case, we build a list of paths for each >> partition usi

Re: Introduce list_reverse() to make lcons() usage less inefficient

2023-02-16 Thread Andres Freund
Hi, On 2023-02-17 11:36:40 +1300, David Rowley wrote: > While working on [1] to make improvements in the query planner around > the speed to find EquivalenceMembers in an EquivalenceClass, because > that patch does have a large impact in terms of performance > improvements, some performance tests

Introduce list_reverse() to make lcons() usage less inefficient

2023-02-16 Thread David Rowley
While working on [1] to make improvements in the query planner around the speed to find EquivalenceMembers in an EquivalenceClass, because that patch does have a large impact in terms of performance improvements, some performance tests with that patch started to highlight some other places that bot