On 09/15/2013 01:35 PM, Kevin Grittner wrote: > Andres Freund <and...@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Ü -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
