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 | CAApHDvpxpU34qfviOPfnN-KbfUx0bQARy3io6i9TVx_dNGcMyQ@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 Wed, 19 Apr 2023 at 16:53, Miroslav Bendik <miroslav.bendik@gmail.com> wrote: > > 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)); > > This code will crash if query_pathkeys is NIL. I need either modify > list_copy_head (v3.1) or add checks before call (v3.2). > > I don't know if it's a good idea to modify list_copy_head. It will add > additional overhead to every call. That's a bug in list_copy_head(). Since NIL is how we represent empty Lists, crashing on some valid representation of a List is not how it should work. That function is pretty new and was exactly added so we didn't have to write list_truncate(list_copy(...), n) anymore. That gets pretty wasteful when the input List is long and we only need a small portion of it. I've just pushed a fix to master for this. See [1]. If you base your patch atop of that you should be able to list list_copy_head() without any issues. David [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e35ded29566f679e52888a8d34468bb51bc78bed
В списке pgsql-hackers по дате отправления: