On 09/15/2013 01:35 PM, Kevin Grittner wrote:
> Andres Freund <andres@2ndquadrant.com> wrote:
>
>> If matview refreshs weren't using plain SQL and thus wouldn't
>> require exposing that operator to SQL I wouldn't have a problem
>> with this...
> If RMVC were the end of the story, it might be worth building up a
> mass of execution nodes directly, although it would be hard to see
> how we could make the right planning choices (e.g., MergeJoin
> versus HashJoin) that way. But the whole incremental maintenance
> area, to have any chance of working accurately and without an
> endless stream of bugs, needs to be based on relational algebra.
> There needs to be a way to express that in a much higher level
> language than execution node creation. If it doesn't use SQL we
> would need to invent a relational language very much like it, which
> would be silly when we have a perfectly good language we can
> already use. The sky is blue; let's move on.
>
> The test for identical records will be needed in SQL if we want to
> have these matview features. We could limit use of that to
> contexts where MatViewIncrementalMaintenanceIsEnabled(), but I
> don't see the point. If someone uses an undocumented operator, and
> uses it inappropriately, they may get a surprising result.
Just remember to document it as "undocumented" so
people will know not to use them ;)
Lots of people were bitten when (undocumented) hash
functions were changed thus breaking hash-based partitioning.
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
