Re: Incremental sort for access method with ordered scan support (amcanorderbyop)
От | David Rowley |
---|---|
Тема | Re: Incremental sort for access method with ordered scan support (amcanorderbyop) |
Дата | |
Msg-id | CAApHDvqqCpQz1y73W=q0+=t7+KkvVLuGV=ejSCS--=xgt=scuA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Incremental sort for access method with ordered scan support (amcanorderbyop) (Miroslav Bendik <miroslav.bendik@gmail.com>) |
Ответы |
Re: Incremental sort for access method with ordered scan support (amcanorderbyop)
Re: Incremental sort for access method with ordered scan support (amcanorderbyop) |
Список | 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
В списке pgsql-hackers по дате отправления: