Re: Again, sorry, caching. - Mailing list pgsql-hackers

From Greg Copeland
Subject Re: Again, sorry, caching.
Date
Msg-id 1016289571.24598.111.camel@mouse.copelandconsulting.net
Whole thread Raw
In response to Again, sorry, caching.  (mlw <markw@mohawksoft.com>)
List pgsql-hackers
On Sat, 2002-03-16 at 08:01, mlw wrote:
[snip]

> "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.
>


Oh ya, I forgot that reply to that part.  I think you are forgetting
that you can use a database to generate a static page.  That is, only
regenerate the static page when the data within the database changes.
Again, this is another example of efficient application caching.  If you
have an application which listens for your cache invalidation event, you
can then recreate your static page.  Again, database result set caching
is not required.  And again, then should be significantly faster than
MySQL's result set caching.  Also worth noting that you could then gzip
your static page (keeping both static pages -- compressed and
uncompressed) resulting in yet another optimization for most web servers
and browsers.

Greg


pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: Re: Again, sorry, caching.
Next
From: Greg Copeland
Date:
Subject: Re: Again, sorry, caching.