From: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
---|---|
To: | mlw <markw(at)mohawksoft(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Again, sorry, caching. |
Date: | 2002-03-16 14:39:31 |
Message-ID: | 1016289571.24598.111.camel@mouse.copelandconsulting.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Copeland | 2002-03-16 14:48:02 | Re: Again, sorry, caching. |
Previous Message | mlw | 2002-03-16 14:36:12 | Re: Again, sorry, caching. |