Обсуждение: Would like to sponsor implementation of MATERIALIZED VIEWS
Hi, as I posted already in the general newsgroup our company has decided that we would like to sponsor the implementation of materialized views for Postgres. However at the moment we have no idea about the complexity of the implementation and therefore what the cost would be. Since the point is already on the TODO List, are there already any (rough) estimates? The TODO List reads: "Right now materialized views require the user to create triggers on the main table to keep the summary table current. SQL syntax should be able to manager the triggers and summary table automatically." And this is what we need. "A more sophisticated implementation would automatically retrieve from the summary table when the main table is referenced, if possible." If this means that e.g. a query would "know by itself" that it could get the data from the view instead of from the main table, then we don't need this feature at the moment. Otherwise: Could anyone explain? Regards, Jan -- Jan Strube www.deriva.de
2008/5/15 <js@deriva.de>: > "A more sophisticated implementation would automatically retrieve from > the summary table when the main table is referenced, if possible." > If this means that e.g. a query would "know by itself" that it could > get the data from the view instead of from the main table, then we > don't need this feature at the moment. Otherwise: Could anyone > explain? That is exactly what it means. Nicolas -- Nicolas Barbier http://www.gnu.org/philosophy/no-word-attachments.html
On May 15, 2008, at 1:40 AM, js@deriva.de wrote: > as I posted already in the general newsgroup our company has decided > that we would like to sponsor the implementation of materialized views > for Postgres. > However at the moment we have no idea about the complexity of the > implementation and therefore what the cost would be. Since the point > is already on the TODO List, are there already any (rough) estimates? > > The TODO List reads: > "Right now materialized views require the user to create triggers on > the main table to keep the summary table current. SQL syntax should be > able to manager the triggers and summary table automatically." > And this is what we need. > > "A more sophisticated implementation would automatically retrieve from > the summary table when the main table is referenced, if possible." > If this means that e.g. a query would "know by itself" that it could > get the data from the view instead of from the main table, then we > don't need this feature at the moment. Otherwise: Could anyone Has anyone contacted the OP about implementing this? Do we have procedure in place for people to sponsor major features like this? -- Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828