Re: limits of max, min optimization

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
>

In response to

Browse pgsql-hackers by date

  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