public inbox for [email protected]
help / color / mirror / Atom feedFrom: Richard Guo <[email protected]>
To: Tom Lane <[email protected]>
Cc: David Rowley <[email protected]>
Cc: Dean Rasheed <[email protected]>
Cc: Ronan Dunklau <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Pavel Luzanov <[email protected]>
Cc: [email protected]
Cc: Ranier Vilela <[email protected]>
Subject: Re: Add proper planner support for ORDER BY / DISTINCT aggregates
Date: Wed, 18 Jan 2023 17:37:01 +0800
Message-ID: <CAMbWs49wdTUJ7g7nX-cKDe1EO5LFQPdqUjMkTcNMfBgv5p+jGg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <3163474.aeNJFYEL58@aivenronan>
<CAApHDvowz-gfbuq=8iwHebRcy4VpFuJv52B3jCcXVi+CPFrd1A@mail.gmail.com>
<[email protected]>
<2202180.iZASKD2KPV@aivenlaptop>
<CAApHDvpkbvDEDJPNZrUqCsCLVC57ZY8qrPn8nGpQSrn4RYstZw@mail.gmail.com>
<CAMbWs4_+5cP+8xjiAc=hds935ZiiG6oepPDeVNovWhQ66DARJw@mail.gmail.com>
<CAApHDvqiEBY5_fVv4ZwUtWDPk0pJ6TdoYKFMwhhF_Gdkv-xAkg@mail.gmail.com>
<CAApHDvr1Sm+g9hbv4REOVuvQKeDWXcKUAhmbK5K+dfun0s9CvA@mail.gmail.com>
<CAApHDvptP-VK+ERLVs6UOAWaCQ7y4bf4_SSfRLCSyKWb-rW5zg@mail.gmail.com>
<CAApHDvrsmvoJ1GF18TCxLL1wE=QrHKdam4dy73a5UF_QpNKqgQ@mail.gmail.com>
<CAEZATCWETioXs5kY8vT6BVguY41_wD962VDk=u_Nvd7S1UXzuQ@mail.gmail.com>
<CAMbWs49sa00xmyw9TfHLYDsHhsud_YEUm3YRkEE4tJrUDqLCgQ@mail.gmail.com>
<CAApHDvruKdB5kaj6W9-kaM=zhMtgD2LvU5YDO3kFui6XSZC5Tg@mail.gmail.com>
<[email protected]>
<CAApHDvov5upudo+03svepBJZ2o7DGtU7X+biVX12ni6ojUDn9A@mail.gmail.com>
<CAApHDvovqhBKjg6+e85Tda-3neZNnKe-w4rRiFOTbHjdWC99AQ@mail.gmail.com>
<CAMbWs49xNn5uLmQGryTGF-LFPpFvouNSa1Y2BqgU_qq_Om=hSQ@mail.gmail.com>
<[email protected]>
On Tue, Jan 17, 2023 at 3:05 PM Tom Lane <[email protected]> wrote:
> Richard Guo <[email protected]> writes:
> > BTW, I wonder if we should have checked CoercionForm before
> > fix_upper_expr_mutator steps into CoerceViaIO->arg to adjust the expr
> > there.
>
> I will just quote what it says in primnodes.h:
>
> * NB: equal() ignores CoercionForm fields, therefore this *must* not carry
> * any semantically significant information.
>
> If you think the planner should act differently for different values of
> CoercionForm, you are mistaken. Maybe this is evidence of some
> previous bit of brain-fade, but if so we need to fix that.
According to this comment in primnodes.h, the planner is not supposed to
treat implicit and explicit casts differently. In this case
set_plan_references is doing its job correctly, to adjust both random()
FuncExprs in targetlist to refer to subplan's output for query 2. As a
consequence we would get a sorted output.
I'm still confused that when the same scenario happens with ORDER BY in
an aggregate function, like in query 1, the result is different in that
we would get an unsorted output.
I wonder if we should avoid this inconsistent behavior.
Thanks
Richard
view thread (5+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Add proper planner support for ORDER BY / DISTINCT aggregates
In-Reply-To: <CAMbWs49wdTUJ7g7nX-cKDe1EO5LFQPdqUjMkTcNMfBgv5p+jGg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox