-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I apologize if this post is inappropriate.
Doing some development work, me and my co-worker discussed some
optimizations strategies. One of the ideas that came up was materialized
views. Trading disk space to summarize queries, and paying for a trigger
waterfall on certain kinds of updates seems like a small price to pay right
now in our situation.
I searched through the archives and I couldn't seem to find anything
relevant.
As I've no familiarity with the internals, but I do know the front-end
pretty well, what can I do to help implement materialized views? Is such an
idea feasible? Is there some reason why it just isn't a good idea? (And if
not, what is a better idea?)
If someone is willing to guide me, I can probably contribute a fair amount
of C code. I do have experience with C.
The bird's eye view of the project would probably be turning a statement (is
there such a statement in SQL92?) in the creation of a table, the initial
population of the table, and the creation of several triggers strategically
placed so that the data in the materialized view table is always in sync.
Direct inserts or updates on the materialized view should be illegal,
except by the triggers. However, perhaps like views work today, we can
allow rules to be added to the table.
Certain restrictions on the materialized views should be enforced: No
mutables, in particular.
- --
Jonathan Gardner
[EMAIL PROTECTED]
Live Free, Use Linux!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE/xNzcWgwF3QvpWNwRAkbiAJ4m1zRPe+y3Tha0649QXH30y9eITwCfTjsv
ow9Nwnnwrc6x9QaAB1AfHWQ=
=Ofb5
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
