Re: [CAUTION!! freemail] Re: Partial aggregates pushdown

Поиск
Список
Период
Сортировка
От vignesh C
Тема Re: [CAUTION!! freemail] Re: Partial aggregates pushdown
Дата
Msg-id CALDaNm0S5fb_8o+TtR8bXf3zOpqabOBLy0EJ3+oVzHH_dzpXvw@mail.gmail.com
обсуждение исходный текст
Ответ на RE: [CAUTION!! freemail] Re: Partial aggregates pushdown  ("Fujii.Yuki@df.MitsubishiElectric.co.jp" <Fujii.Yuki@df.MitsubishiElectric.co.jp>)
Ответы Re: Partial aggregates pushdown
Список pgsql-hackers
On Thu, 7 Dec 2023 at 05:41, Fujii.Yuki@df.MitsubishiElectric.co.jp
<Fujii.Yuki@df.mitsubishielectric.co.jp> wrote:
>
> Hi Mr.Haas.
>
> > -----Original Message-----
> > From: Robert Haas <robertmhaas@gmail.com>
> > Sent: Wednesday, December 6, 2023 10:25 PM
> > On Wed, Dec 6, 2023 at 3:41 AM Fujii.Yuki@df.MitsubishiElectric.co.jp
> > <Fujii.Yuki@df.mitsubishielectric.co.jp> wrote:
> > > Are you concerned about the hassle and potential human errors of
> > > manually adding new partial aggregation functions, rather than the catalog becoming bloated?
> >
> > I'm concerned about both.
> Understood. Thank you for your response.
>
> > > The process of creating partial aggregation functions from aggregation
> > > functions can be automated, so I believe this issue can be resolved.
> > > However, automating it may increase the size of the patch even more, so overall, approach#2 might be better.
> > > To implement approach #2, it would be necessary to investigate how much additional code is required.
> >
> > Yes. Unfortunately I fear that there is quite a lot of work left to do here in order to produce a committable
feature.To me it 
> > seems necessary to conduct an investigation of approach #2. If the result of that investigation is that nothing
major
> > stands in the way of approach #2, then I think we should adopt it, which is more work. In addition, the problems
around
> > transmitting serialized bytea blobs between machines that can't be assumed to fully trust each other will need to
be
> > addressed in some way, which seems like it will require a good deal of design work, forming some kind of consensus,
and
> > then implementation work to follow. In addition to that there may be some small problems that need to be solved at
a
> > detail level, such as the HAVING issue. I think the last category won't be too hard to sort out, but that still
leavestwo really 
> > major areas to address.
> Yes, I agree with you. It is clear that further investigation and discussion are still needed.
> I would be grateful if we can resolve this issue gradually. I would also like to continue the discussion if possible
inthe future. 

Thanks for all the efforts on this patch. I have changed the status of
the commitfest entry to "Returned with Feedback" as there is still
some work to get this patch out. Feel free to continue the discussion
and add a new entry when the patch is in a reviewable shape.

Regards,
Vignesh



В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: [PoC/RFC] Multiple passwords, interval expirations
Следующее
От: vignesh C
Дата:
Сообщение: Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500