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