From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: limits of max, min optimization |
Date: | 2022-07-18 14:32:56 |
Message-ID: | CAFj8pRC5-bNOrhMhznFcZc58yMkaR_w9BnrtLFTR59VW4dzz8Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
po 18. 7. 2022 v 16:29 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > On 2022-Jul-18, Pavel Stehule wrote:
> >> I am trying to fix one slow query, and found that optimization of min,
> max
> >> functions is possible only when there is no JOIN in the query.
>
> > See preprocess_minmax_aggregates() in
> > src/backend/optimizer/plan/planagg.c
> > Maybe it is possible to hack that code so that this case can be handled
> > better.
>
> The comments show this was already thought about:
>
> * We also restrict the query to reference exactly one table, since
> join
> * conditions can't be handled reasonably. (We could perhaps handle a
> * query containing cartesian-product joins, but it hardly seems worth
> the
> * trouble.)
>
>
Thank you for reply
Regards
Pavel
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-07-18 14:33:04 | doc: mentioned CREATE+ATTACH PARTITION as an alternative to CREATE TABLE..PARTITION OF |
Previous Message | Tom Lane | 2022-07-18 14:29:07 | Re: limits of max, min optimization |