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

Поиск
Список
Период
Сортировка
От Fujii.Yuki@df.MitsubishiElectric.co.jp"
Тема RE: [CAUTION!! freemail] Re: Partial aggregates pushdown
Дата
Msg-id TYAPR01MB5514C939F39F97BC171F58FD958BA@TYAPR01MB5514.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Partial aggregates pushdown  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [CAUTION!! freemail] Re: Partial aggregates pushdown  (Robert Haas <robertmhaas@gmail.com>)
Re: [CAUTION!! freemail] Re: Partial aggregates pushdown  (vignesh C <vignesh21@gmail.com>)
Список pgsql-hackers
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 in
thefuture.
 

Sincerely yours,
Yuuki Fujii

--
Yuuki Fujii
Information Technology R&D Center Mitsubishi Electric Corporation

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

Предыдущее
От: kovert@omniscient.com
Дата:
Сообщение: pg16 && GSSAPI && Heimdal/Macos
Следующее
От: Noah Misch
Дата:
Сообщение: Re: reindexing an invalid index should not use ERRCODE_INDEX_CORRUPTED