From: | Greg Copeland <greg(at)CopelandConsulting(dot)Net> |
---|---|
To: | mlw <markw(at)mohawksoft(dot)com> |
Cc: | "Mattew T(dot) O'Connor" <matthew(at)www2(dot)us(dot)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Again, sorry, caching. |
Date: | 2002-03-18 15:40:05 |
Message-ID: | 1016466005.14670.27.camel@mouse.copelandconsulting.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2002-03-18 at 08:15, mlw wrote:
> "Mattew T. O'Connor" wrote:
> >
[snip]
>
> >The primary use that you have suggested is for web sites,
> > and they certainly won't mind of the cache is 0.3seconds out of date.
>
> Again, if they don't care about accuracy, then they will use MySQL. PostgreSQL
> is a far better system. Making PostgreSQL less accurate, less "correct" takes
> away, IMHO, the very reasons to use it.
>
If you are using a web site and you need real time data within 0.3s,
you've implemented on the wrong platform. It's as simple as that. In
the web world, there are few applications where a "0.3s" of a window is
notable. After all, that "0.3s" of a window can be anywhere within the
system, including the web server, network, any front end caches, dns
resolutions, etc.
I tend to agree with Mettew. Granted, there are some application
domains where this can be critical...generally speaking, web serving
isn't one of them.
That's why all of the solutions I offered were pointedly addressing a
web server scenario and not a generalized database cache. I completely
agree with you on that. In a generalized situation, the database should
be managing and caching the data (which it already does).
Greg
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-03-18 16:08:11 | Re: Again, sorry, caching. |
Previous Message | Tom Lane | 2002-03-18 15:29:10 | Re: postgres is not using tas |