Re: Implementing Incremental View Maintenance
От | Greg Stark |
---|---|
Тема | Re: Implementing Incremental View Maintenance |
Дата | |
Msg-id | CAM-w4HN6U5CM+PBsTg97QG0kk2PEW_tvh09HWnZnjW1Tfk7Q7w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Implementing Incremental View Maintenance (Yugo NAGATA <nagata@sraoss.co.jp>) |
Ответы |
Re: Implementing Incremental View Maintenance
|
Список | pgsql-hackers |
I'm trying to figure out how to get this feature more attention. Everyone agrees it would be a huge help but it's a scary patch to review.
On Fri., Apr. 22, 2022, 08:01 Yugo NAGATA, <nagata@sraoss.co.jp> wrote:
On Fri, 22 Apr 2022 11:29:39 +0900
Yugo NAGATA <nagata@sraoss.co.jp> wrote:
> Hi,
>
> On Fri, 1 Apr 2022 11:09:16 -0400
> Greg Stark <stark@mit.edu> wrote:
>
> > This patch has bitrotted due to some other patch affecting trigger.c.
> >
> > Could you post a rebase?
> >
> > This is the last week of the CF before feature freeze so time is of the essence.
>
> I attached a rebased patch-set.
>
> Also, I made the folowing changes from the previous.
>
> 1. Fix to not use a new deptye
>
> In the previous patch, we introduced a new deptye 'm' into pg_depend.
> This deptype was used for looking for IVM triggers to be removed at
> REFRESH WITH NO DATA. However, we decided to not use it for reducing
> unnecessary change in the core code. Currently, the trigger name and
> dependent objclass are used at that time instead of it.
>
> As a result, the number of patches are reduced to nine from ten.
> 2. Bump the version numbers in psql and pg_dump
>
> This feature's target is PG 16 now.
Sorry, I revert this change. It was too early to bump up the
version number.
--
Yugo NAGATA <nagata@sraoss.co.jp>
В списке pgsql-hackers по дате отправления: