Re: pg16: XX000: could not find pathkey item to sort

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg16: XX000: could not find pathkey item to sort
Date: 2023-10-08 10:52:38
Message-ID: CAMbWs48VKgJyqfDNtKsYnNsPYWqA=stPKenehVz1NN0HTFV9mg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 5, 2023 at 2:26 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> So in short, I propose the attached fix without any regression tests
> because I feel that any regression test would just mark that there was
> a big in create_agg_path() and not really help with ensuring we don't
> end up with some similar problem in the future.

If the pathkeys that were added by adjust_group_pathkeys_for_groupagg()
are computable from the targetlist, it seems that we do not need to trim
them off, because prepare_sort_from_pathkeys() will add resjunk target
entries for them. But it's also no harm if we trim them off. So I
think the patch is a pretty safe fix. +1 to it.

> I have some concerns that the assert_pathkeys_in_target() function
> might be a little heavyweight for USE_ASSERT_CHECKING builds. So I'm
> not proposing to commit that without further discussion.

Yeah, it looks like some heavy to call assert_pathkeys_in_target() for
each path node. Can we run some benchmarks to see how much overhead it
would bring to USE_ASSERT_CHECKING build?

Thanks
Richard

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2023-10-08 13:20:32 Re: CREATE DATABASE with filesystem cloning
Previous Message Richard Guo 2023-10-08 08:26:43 Re: BUG #17540: Prepared statement: PG switches to a generic query plan which is consistently much slower