From: | Adam Brusselback <adambrusselback(at)gmail(dot)com> |
---|---|
To: | denty <denty(at)qqdd(dot)eu> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Implementing Incremental View Maintenance |
Date: | 2018-12-31 16:20:11 |
Message-ID: | CAMjNa7cogDibpuGF=MDdaJGxKmnnz7pcxwp2ZwFFE-WjxUoNsA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all, just wanted to say I am very happy to see progress made on this,
my codebase has multiple "materialized tables" which are maintained with
statement triggers (transition tables) and custom functions. They are ugly
and a pain to maintain, but they work because I have no other
solution...for now at least.
I am concerned that the eager approach only addresses a subset of the MV use
> case space, though. For example, if we presume that an MV is present
> because
> the underlying direct query would be non-performant, then we have to at
> least question whether applying the delta-update would also be detrimental
> to some use cases.
>
I will say that in my case, as long as my reads of the materialized view
are always consistent with the underlying data, that's what's important. I
don't mind if it's eager, or lazy (as long as lazy still means it will
refresh prior to reading).
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2018-12-31 17:25:51 | Re: Is MinMaxExpr really leakproof? |
Previous Message | Nikolay Shaplov | 2018-12-31 16:19:39 | Re: [PATCH] check for ctags utility in make_ctags |