Re: Incremental sort for access method with ordered scan support (amcanorderbyop)
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Miroslav Bendik <miroslav.bendik@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, pgsql-hackers@postgresql.org
Date: 2023-04-18T09:50:21Z
Lists: pgsql-hackers
On Tue, 18 Apr 2023 at 19:29, Miroslav Bendik <miroslav.bendik@gmail.com> wrote:
> here is an updated patch with proposed changes.
Here's a quick review:
1. I don't think this is required. match_pathkeys_to_index() sets
these to NIL and they're set accordingly by the other code paths.
- List *orderbyclauses;
- List *orderbyclausecols;
+ List *orderbyclauses = NIL;
+ List *orderbyclausecols = NIL;
2. You can use list_copy_head(root->query_pathkeys,
list_length(orderbyclauses)); instead of:
+ useful_pathkeys = list_truncate(list_copy(root->query_pathkeys),
+ list_length(orderbyclauses));
3. The following 2 changes don't seem to be needed:
@@ -3104,11 +3100,11 @@ match_pathkeys_to_index(IndexOptInfo *index,
List *pathkeys,
/* Pathkey must request default sort order for the target opfamily */
if (pathkey->pk_strategy != BTLessStrategyNumber ||
pathkey->pk_nulls_first)
- return;
+ break;
/* If eclass is volatile, no hope of using an indexscan */
if (pathkey->pk_eclass->ec_has_volatile)
- return;
+ break;
There's no code after the loop you're breaking out of, so it seems to
me that return is the same as break and there's no reason to change
it.
David
Commits
-
Allow Incremental Sorts on GiST and SP-GiST indexes
- 625d5b3ca096 17.0 landed
-
Fix list_copy_head() with empty Lists
- 63a03aea6bc8 15.3 landed
- e35ded29566f 16.0 landed