From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Introduce list_reverse() to make lcons() usage less inefficient |
Date: | 2023-02-17 03:35:41 |
Message-ID: | CAApHDvqxvGuET5MAM5K=XX9=qbqLS6ZXP49h2wihOsZQbrSqCg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 17 Feb 2023 at 13:23, Andres Freund <andres(at)anarazel(dot)de> 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 open code.
That seems fair. I think open coding is a better option. I had a go
at foreach_reverse recently and decided to keep clear of it due to
behavioural differences with foreach_delete_current().
I've attached a patch for this. It seems to have similar performance
to the list_reverse()
$ psql -c "explain (analyze, timing off) select * from lp order by a
desc" postgres | grep "Planning Time"
Planning Time: 522.554 ms <- cold relcache
Planning Time: 467.776 ms
Planning Time: 466.424 ms
David
Attachment | Content-Type | Size |
---|---|---|
optimize_generate_orderedappend_paths.patch | text/plain | 2.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-02-17 03:40:00 | Re: Reducing System Allocator Thrashing of ExecutorState to Alleviate FDW-related Performance Degradations |
Previous Message | Amit Kapila | 2023-02-17 03:24:02 | Re: DDL result is lost by CREATE DATABASE with WAL_LOG strategy |