From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
---|---|
To: | Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Incremental View Maintenance, take 2 |
Date: | 2024-08-20 06:09:49 |
Message-ID: | CALdSSPhzzJffBEDaihtT5jXpq_aF++wX2BfJhZkrnqn-E0S_LQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 20 Aug 2024 at 02:14, Kirill Reshke <reshkekirill(at)gmail(dot)com> wrote:
> == Other thoughts
>
> In OLAP databases (see [2]), IVM opens the door for 'view
> exploitation' feature. That is, use IVM (which is always up-to-date)
> for query execution. But current IVM implementation is not compatible
> with Cloudberry Append-optimized Table Access Method. The problem is
> the 'table_tuple_fetch_row_version' call, which is used by
> ivm_visible_in_prestate to check tuple visibility within a snapshot. I
> am trying to solve this somehow. My current idea is the following:
> multiple base table modification via single statement along with tuple
> deletion from base tables are features. We can error-out these cases
> (at M.V. creation time) all for some TAMs, and support only insert &
> truncate. However, I don't know how to check if TAM supports
> 'tuple_fetch_row_version' other than calling it and receiving
> ERROR[3].
>
I reread this and I find this a little bit unclear. What I'm proposing
here is specifying the type of operations IVM supports on creation
time. So, one can run
CREATE IVM immv1 WITH (support_deletion = true/false,
support_multiple_relation_change = true/false). Then, in the query
execution time, we just ERROR if the query leads to deletion from IVM
and support_deletion if false.
--
Best regards,
Kirill Reshke
From | Date | Subject | |
---|---|---|---|
Next Message | Xiaoran Wang | 2024-08-20 06:37:11 | Re: Improve pg_re_throw: check if sigjmp_buf is valid and report error |
Previous Message | Amit Kapila | 2024-08-20 06:06:45 | Re: [bug fix] prepared transaction might be lost when max_prepared_transactions is zero on the subscriber |