Karel Zak wrote: > > On Sat, Mar 16, 2002 at 09:01:28AM -0500, mlw wrote: > > > "If it is mostly static data, why not just make it a static page?" > > Because a static page is a maintenance nightmare. One uses a database in a web > > site to allow content to be changed and upgraded dynamically and with a minimum > > of work. > > It's ugly argumentation for DB cache. What generate web page after data > change and next time use it as static? > > > I was thinking that it could be implemented as a keyword or comment in a query. > > Such as: > > > > select * from table where column = 'foo' cacheable > > You can insert "mostly static data" into temp table and in next queries > use this temp table. After update/delete/insert can your application > rebuild temp table (or by trigger?).
Yes, I could, as could most of the guys reading these messages. I am thinking about a feature in PostgreSQL that would make that easier for the average DBA or web producer. Lets face it, MySQL wins a lot of people because they put in features that people want. All the ways people have suggested to "compete" with MySQL's caching have been ugly kludges. I understand the there is an amount of work involved with doing caching, and the value of caching is debatable by some, however, it is demonstrable that caching can improve a very common, albeit specific, set of deployments. Also, managing data is the job of the database, not the application. It does belong in PostgreSQL, if someone is forced to write a caching scheme around PostgreSQL, it is because PostgreSQL lacks that feature. ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
